標籤:
MongoDB 資料移轉和同步MongoDB的資料同步複製
mongodb的複製至少需要兩個執行個體。其中一個是主節點master,負責處理用戶端請求,其餘的都是slave,負責從master上複製資料。
master寫處理:
master負責接收寫請求,具體的流程為:
- 如果開啟journal功能,則先將寫請求記錄到journal中,然後批量執行,同時將操作記錄到oplog中;
- 如果未開啟journal功能,則對每個寫請求進行單獨操作,然後寫入oplog。
註:oplog是等冪的,當有累加操作inc時,會記錄成set操作,從而無論重複執行多少次操作獲得的結果都是一樣的。
從節點同步:
- 如果是一個新的從節點,首先先從master的資料庫檔案進行複製,同時記錄起始時間;當從節點從master的複製完成後,會根據複製的起始時間開始追oplog,進而與master進行同步。
- 初始化同步完成後的slave定期從master的oplog中擷取最新的操作,然後對自己的資料副本執行這些操作,從而保證slave的資料與master最終一致性。
注意:當slave同步的速度趕不上master更新的速度時,oplog會因為追加了過多的操作而發生將舊記錄覆蓋掉,這樣slave可能無法保證同步所有的資料,這時,slave會開始從頭重新同步。
MongoDB的主從同步原理
主從複製是MongoDB最常用的複製方式,這種方式很靈活,可用於備份、故障恢複和讀擴充等。需要在啟動進程時指定master和slave,slave要指定master的地址,這種方式沒有自動容錯移轉功能。
預設情況下,slave既不能寫也不能讀,但可以通過配置將slave改為可讀模式,從而做到讀寫分離,提高系統效能。
操作
操作可以選擇兩種方式:命令列和設定檔。
命令列
master啟動命令
# mongod --config /etc/mongodb.conf --master
slave啟動命令
# mongod --config /etc/mongodb.conf --slave --autoresync --slavedelay=10 --source master-ip:master-port
配置
master配置:
master = true
slave配置:
slave = true
autoresync = true
slavedelay = 10
選項
-only
在從節點上指定只複製特定的某個資料庫(預設是複製所有資料庫)。
-slavedelay
用在從節點上,當應用主節點的操作時,從節點增加延時複製(單位秒)。這樣就能輕鬆設定延時從節點,這種節點對使用者無意中刪除重要文檔或者插入垃圾資料等有防護作用,這些不良操作都會被複製到所有的從節點上,通過延時執行操作,可以有個恢複的時間差。
-fastsync
以主節點的資料快照為基礎啟動從節點。如果資料目錄一開始是主節點的資料快照,從節點用這個選項啟動要比做完整的同步快的多。
-autoresync
如果從節點與主節點不同步了,則自動重新同步。
-oplogsize
主節點oplog的大小(單位MB)。預設的oplog大小是剩餘磁碟空間的5%。
MongoDB複本集原理
複本集(Replica Set)就是有自動故障恢複功能的主從叢集。主從叢集和複本集最明顯的區別是複本集沒有固定的”主節點”,整個叢集會選舉出一個”主節點”,當其不能工作時則變更到其他節點.複本集總會有一個活躍節點(primary)和一個或多個備份節點(secondary)。
複本集可以在活躍節點有問題時自動切換。
節點類型
任何時間,叢集中只有一個活躍節點,其他的都是備份節點.活躍節點實際上是活躍伺服器,指定的活躍節點可以隨時間而改變。
有幾種不同類型的節點可以存在與複本集中:
standard 標準節點
這是常規節點,它儲存一份完整的資料副本,參與選舉投票有可能成為活躍節點。
passive 被動結點
儲存了完整的資料副本,參與投票,不能成為活躍節點。
arbiter 仲裁者
仲裁者只能參與投票,不接收複製的資料,也不能成為活躍節點。
優先順序
每個參與節點(非仲裁)有優先權,優先權按照優先值從大到小,預設優先順序為1,可以是0-1000(含)。
在節點配置中修改priority鍵,來配置標準節點或者被動節點。
> members.push({"_id":3,"host":"127.0.0.1:10002","priority":40})
“arbiterOnly”鍵可以指定仲裁節點
> members.push({"_id":4,"host":"127.0.0.1:10003","arbiterOnly":true})
備份節點會從活躍節點抽取oplog,並執行操作,就像活躍備份系統中的備份伺服器一樣.活躍節點也會寫操作到自己的本地oplog.oplog中的操作包含嚴格遞增的序號,這個序號來判定資料的時效性。
選舉策略
如果活躍節點出現故障,其餘節點會選一個新的活躍節點.選舉過程可以由任何非活躍節點發起,新的活躍節點由複本集中的大多數選舉產生。其中仲裁節點也參與選舉,避免出現僵局。新的活躍節點將是優先順序最高的節點,優先順序相同則資料較新的節點獲勝。
不論活躍節點何時變化,新的活躍節點的資料就被假定為系統的最新資料。對其他幾點(原來的活躍節點)的操作都會復原,即便是之前的活躍節點已經恢複工作了。為了完成復原,所有節點串連新的活躍節點後重新同步。這些節點會查看自己的oplog,找出活躍節點沒有的操作,然後向活躍節點請求這些操作影響的文檔最新副本。正在執行重新同步的節點被視為恢複中,在完成這個過程之前不能成為活躍節點的候選者。
操作命令列初始化操作
設定複本集比設定主從叢集稍微複雜一點。
先給複本集起個名稱,是為了易於與別的複本集區分,也是為了方便將整個集合視為一個整體,這裡取名:refactor
啟動伺服器–replSet的作用是讓伺服器知道這個“refactor”複本集還有別的同伴,位置在 refactor/127.0.0.1:10001
# mongod --dbpath /data1/mongodb --port 10000 --replSet refactor/127.0.0.1:10001 --logpath /data1/log/mongodb/mongodb.log --rest
以同樣的方式啟動另一台:
# mongod --dbpath /data1/mongodb --port 10001 --replSet refactor/127.0.0.1:10000 --logpath /data1/log/mongodb/mongodb.log --rest
如果想要添加第三台,兩種方式:
# mongod --dbpath /data1/mongodb --port 10002 --replSet refactor/127.0.0.1:10000 --logpath /data1/log/mongodb/mongodb.log --rest
註:複本集有自動檢測功能:在其中指定單台伺服器後,MongoDB就會自動搜尋並串連其餘的節點。
mongo內部命令初始化操作
> use admin> db.runCommand( { "replSetInitiate": { "_id":"refactor",//複本集的名稱 "members"://複本集中的伺服器列表 [ { "_id":1,//每個伺服器的唯一id "host":"127.0.0.1:10000"//指定伺服器的主機 }, { "_id":2, "host":"127.0.0.1:10001" } ] } })>
MongoDB的資料移轉mongodump & mongorestoreMongoDB資料備份
在Mongodb中我們使用mongodump命令來備份MongoDB資料。該命令可以匯出所有資料到指定目錄中。
mongodump命令可以通過參數指定匯出的資料量級轉存的伺服器。
文法
mongodump命令指令碼文法如下:
# mongodump -h dbhost -d dbname -o dbdirectory
- -h:
目標MongDB所在伺服器位址,例如:127.0.0.1,當然也可以指定連接埠號碼:127.0.0.1:27017
- -d:
需要備份的資料庫執行個體,例如:test
- -o:
備份的資料存放位置,例如:/data/mongodb/backup,當然該目錄需要提前建立,在備份完成後,系統自動在dump目錄下建立一個test目錄,這個目錄裡面存放該資料庫執行個體的備份資料。
MongoDB資料恢複
mongodb使用 mongorerstore 命令來恢複備份的資料。
文法
mongorestore命令指令碼文法如下:
# mongorestore -h dbhost -d dbname --directoryperdb dbdirectory
- -h:
MongoDB所在伺服器位址
- -d:
需要恢複的資料庫執行個體,例如:test,當然這個名稱也可以和備份時候的不一樣,比如test2
- -directoryperdb:
備份資料所在位置,例如:c:\data\dump\test,這裡為什麼要多加一個test,而不是備份時候的dump,讀者自己查看提示吧!
- -drop:
恢複的時候,先刪除當前資料,然後恢複備份的資料。就是說,恢複後,備份前添加修改的資料都會被刪除,慎用!
日誌系統日誌
系統日誌在Mongdb資料中很中重要,它記錄mongodb啟動和停止的操作,以及伺服器在運行過程中發生的任何異常資訊。
配置路徑:
# mongod --logpath=‘/data/db/log/server.log‘ -logappend
journal日誌
Jouranl日誌通過預寫入的redo日誌為mongodb增加了額外的可靠性保障。開啟該功能時候,資料的更新就先寫入Journal日誌,定期集中提交(目前是每100ms提交一次) ,然後在正式資料執行更改。
開啟檔案:
# mongod --journal
oplog日誌
Mongodb的高可用複製策略有一個叫做Replica Sets.ReplicaSet複製過程中有一個伺服器充當主伺服器,而一個或多個充當從伺服器,主服務將更新寫入一個本地的collection中,這個collection記錄著發生在主伺服器的更新操作,並將這些操作分發到從伺服器上。這個日誌是Capped Collection。
註:Capped Collections 是效能出色的有著固定大小的集合,以LRU(Least Recently Used 最近最少 使用)規則和插入順序進行 age-out(老化移出)處理,自動維護集合中對象的插入順序,在建立時要預先指定大小。
# mongod --oplogSize=1024 #單位是M
slow日誌
慢查詢記錄了執行時間超過了所設定時間閥值的動作陳述式。慢查詢日誌對於發現效能有問題的語句很有協助,建議開啟此功能並經常分析該日誌的內容。
要配置這個功能只需要在mongod啟動時候設定profile參數即可。例如想要將超過5s的操作都記錄,可以使用如下語句:
# mongod --profile=1 --slowms=5
參考文章
- Master Slave Replication
- mongodb複製
- mongodb複製原理
- MongoDB 備份(mongodump)與恢複(mongorerstore)
MongoDB 資料移轉和同步