1. 程式人生 > 資訊 >微星預計 DDR5 記憶體比 DDR4 貴 50~60%,需要大約 2 年時間才能降到目前水平

微星預計 DDR5 記憶體比 DDR4 貴 50~60%,需要大約 2 年時間才能降到目前水平

伺服器配置
HOSTNAME  IP            應用
1-81      172.16.1.81   mongodb-3.6.23
1-82      172.16.1.82   mongodb-3.6.23
1-83      172.16.1.83   mongodb-3.6.23

0 副本集資料過程
(1) Primary節點寫入資料,Secondary通過讀取Primary的oplog得到複製資訊,開始複製資料並且將複製資訊寫入到自己
的oplog。如果某個操作失敗,則備份節點停止從當前資料來源複製資料。如果某個備份節點由於某些原因掛掉了,當重新啟動
後就會自動從oplog的最後一個操作開始同步,同步完成後,將資訊寫入自己的oplog,由於複製操作是先複製資料,複製完
成後再寫入oplog,有可能相同的操作會同步兩份,不過MongoDB在設計之初就考慮到這個問題,將oplog的同一個操作執行
多次,與執行一次的效果是一樣的。簡單的說就是:
當Primary節點完成資料操作後,Secondary會做出一系列的動作保證資料的同步:
1) 檢查自己local庫的oplog.rs集合找出最近的時間戳。 2) 檢查Primary節點local庫oplog.rs集合,找出大於此時間戳的記錄。 3) 將找到的記錄插入到自己的oplog.rs集合中,並執行這些操作。 (2) 副本集的同步和主從同步一樣,都是非同步同步的過程,不同的是副本集有個自動故障轉移的功能。其原理是,slave端 從primary端獲取日誌,然後在自己身上完全順序的執行日誌所記錄的各種操作(該日誌是不記錄查詢操作的),這個日誌就 是local資料庫中的oplog.rs表,預設在64位機器上這個表是比較大的,佔磁碟大小的5%,oplog.rs的大小可以在啟動參 數中設定
"--oplogSize 1000",單位是M。 (3) 注意,在副本集的環境中,要是所有的Secondary都宕機了,只剩下Primary,最後Primary會變成Secondary,不能 提供服務。 (4) mongodb預設是從主節點讀寫資料的,副本節點上不允許讀寫,需要設定副本節點可以讀。 1 配置引數 # cat > /opt/mongodb/conf/mongodb.conf << EOF dbpath=/opt/mongodb/data #資料庫檔案位置 bind_ip=172.16.1.81 #繫結地址,預設127.0.0.1,只能通過本地連線,每個節點繫結的ip不一樣。 port
=27017 #埠,預設27017,MongoDB的預設服務TCP埠,監聽客戶端連線。 journal=true #啟用日誌檔案,預設啟用。 logpath=/opt/mongodb/log/mongodb.log #日誌檔案位置,該日誌檔案必須存在,否則會報錯 pidfilepath=/opt/mongodb/mongodb.pid #後臺程序pid檔案 logappend=true #以追加方式寫入日誌。 quiet=true #這個選項可以過濾掉一些無用的日誌資訊,若需要除錯使用請設定為false。 fork=true #以守護程序方式執行 #shardsvr=true #分片配置 #directoryperdb=false #是否修改資料為目錄儲存模式,預設為false #auth=true #keyFile=/opt/mongodb/conf/mongodb-keyfile #叢集私鑰的完整路徑,只對於ReplicaSet架構有效,auth=true時配置此項 replSet=mongodb-replset # mongodb副本集名稱 oplogSize=40960 #設定oplog的大小,節點操作記錄儲存到local的oplog中,用於從庫拉取, #單位mb,磁碟滿後迴圈覆蓋。預設佔磁碟大小的5%。 EOF 2 建立叢集 # mongo --host 172.16.1.81 --port 27017 > use admin #定義副本集配置變數,這裡的 _id:"mongodb-replset"和mongodb.conf配置引數"replSet"要保持一樣 > config = { _id:"mongodb-replset", members:[{_id:0,host:"172.16.1.81:27017"},{_id:1,host:"172.16.1.82:27017"},{_id:2,host:"172.16.1.83:27017"}]} #初始化副本集配置 > rs.initiate(config) # 檢視叢集配置 > rs.conf() #檢視叢集節點的狀態 > rs.status() 注: 副本集配置成功後,172.16.1.81為主節點PRIMARY,172.16.1.82/83為副本節點SECONDARY。 health:1 1狀態是正常,0表明異常 state:1 值小的是primary節點、值大的是secondary節點 # 設定延遲從庫 > cfg = rs.conf() > cfg.members[2].priority = 0 > cfg.members[2].hidden = true > cfg.members[2].slaveDelay = 3600 > rs.reconfig(cfg) 注: 這裡將id為2的172.16.1.83節點作為延遲從庫,延遲時間為3600s。 cfg.members[2].priority = 0 表示延遲從庫永遠不會變為主節點。 3 新增認證 (1) 建立管理使用者(在主節點上操作) # mongo --host 172.16.1.81 --port 27017 > use admin > db.createUser({user: "root",pwd: "123456",roles: [ { role: "root", db: "admin" } ]}) > exit (2) 分發認證key(在主節點上操作) # openssl rand -base64 741 > /opt/mongodb/conf/mongodb-keyfile # chmod 600 /opt/mongodb/conf/mongodb-keyfile # chown mongodb:mongodb /opt/mongodb/conf/mongodb-keyfile # scp -p /opt/mongodb/conf/mongodb-keyfile root@172.16.1.82:/opt/mongodb/conf/ # scp -p /opt/mongodb/conf/mongodb-keyfile root@172.16.1.83:/opt/mongodb/conf/ # ssh -p 22 root@172.16.1.82 "chown mongodb:mongodb /opt/mongodb/conf/mongodb-keyfile" # ssh -p 22 root@172.16.1.83 "chown mongodb:mongodb /opt/mongodb/conf/mongodb-keyfile" (3) 修改配置檔案(在三個節點上分別操作) # cat >> /opt/mongodb/conf/mongodb.conf << EOF auth=true keyFile=/opt/mongodb/conf/mongodb-keyfile EOF (4) 重啟mongodb服務(依次重啟三個節點) # systemctl restart mongodb.service # systemctl status mongodb.service (5) 測試 # 主節點 # mongo --host 172.16.1.81 --port 27017 -uroot -p'123456' admin > use master_slave_test > function add(){var i = 0;for(;i<7;i++){db.persons.insert({"name":"master_slave_test"+i})}} > add() > db.persons.find() # 從節點 # mongo --host 172.16.1.82 --port 27017 -uroot -p'123456' admin > db.getMongo().setSecondaryOk() > use master_slave_test > db.persons.find() # mongo --host 172.16.1.83 --port 27017 -uroot -p'123456' admin > db.getMongo().setSecondaryOk() > use master_slave_test > db.persons.find() 注: # mongodb預設是從主節點讀寫資料的,副本節點上不允許讀寫,需要設定副本節點可以讀 mongodb-replset:SECONDARY> db.getMongo().setSecondaryOk() <=> mongodb-replset:SECONDARY> rs.secondaryOk() 4 副本集的工作流程 (1) mongodb的oplog.rs表記錄日誌是預設開啟的,大小為磁碟的5%。 (2) 在MongoDB副本集中,主節點負責處理客戶端的讀寫請求,備份節點則負責對映主節點的資料。備份節點的工作原理過程可以大 致描述為,備份節點定期輪詢主節點上的資料操作,然後對自己的資料副本進行這些操作,從而保證跟主節點的資料同步。至於主節 點上的所有資料庫狀態改變的操作,都會存放在一張特定的系統表中。備份節點則是根據這些資料進行自己的資料更新。 (3) oplog 上面提到的資料庫狀態改變的操作稱為oplog(operation log,主節點操作記錄)。oplog儲存在local資料庫的"oplog.rs"表中。 副本集中備份節點非同步的從主節點同步oplog,然後重新執行它記錄的操作,以此達到了資料同步的作用。關於oplog有幾個注意的 地方: 1) oplog只記錄改變資料庫狀態的操作。 2) 儲存在oplog中的操作並不是和主節點執行的操作完全一樣,例如"$inc"操作就會轉化為"$set"操作。 3) oplog儲存在固定集合中(capped collection),當oplog的數量超過oplogSize,新的操作就會覆蓋就的操作。 (4) 資料同步 在副本集中,有兩種資料同步方式: 1) initial sync(初始化): 這個過程發生在當副本集中建立一個新的資料庫或其中某個節點剛從宕機中恢復,或者向副本集中添 加新的成員的時候,預設的副本集中的節點會從離它最近的節點複製oplog來同步資料,這個最近的節點可以是primary也可以是擁 有最新oplog副本的secondary節點。該操作一般會重新初始化備份節點,開銷較大。 2) replication(複製): 在初始化後這個操作會一直持續的進行著,以保持各個secondary節點之間的資料同步。 (5) initial sync 當遇到無法同步的問題時,只能使用以下兩種方式進行initial sync了 1) 第一種方式就是停止該節點,然後刪除目錄中的檔案,重新啟動該節點。這樣這個節點就會執行initial sync。 注意: 通過這種方式sync的時間是根據資料量大小的,如果資料量過大,sync時間就會很長,同時會有很多網路傳輸,可能會影響 其他節點的工作。 2) 第二種方式是停止該節點,然後刪除目錄中的檔案,找一個比較新的節點,然後把該節點目錄中的檔案拷貝到要sync的節點目錄 中。 3) 通過上面兩種方式中的一種,都可以重新恢復宕機的節點。 (6) 副本集管理 1) 檢視oplog的資訊通過"db.printReplicationInfo()"命令可以檢視oplog的資訊,欄位說明: configured oplog size # oplog 檔案大小 log length start to end # oplog 日誌的啟用時間段 oplog first event time # 第一個事務日誌的產生時間 oplog last event time # 最後一個事務日誌的產生時間 now: # 現在的時間 2) 檢視slave狀態通過"db.printSlaveReplicationInfo()"可以檢視slave的同步狀態當插入一條新的資料,然後重新檢查 slave狀態時,就會發現sync時間更新了。