深入淺出MongoDB復(fù)制

lyhabc

MongoDB復(fù)制簡(jiǎn)介
MongoDB添加從庫(kù)
MongoDB復(fù)制流程詳解
MongoDB高可用
MongoDB復(fù)制總結(jié)
1、MongoDB復(fù)制簡(jiǎn)介
本章節(jié)首先會(huì)給大家簡(jiǎn)單介紹一些MongoDB復(fù)制的一些基本概念，便于大家對(duì)后面內(nèi)容的理解。

1.1、基本介紹
MongoDB有副本集及主從復(fù)制兩種模式，今天給大家介紹的是副本集模式，因?yàn)橹鲝哪Ｊ皆贛ongoDB 3.6也徹底廢棄不使用了。MongoDB副本集有Primary、Secondary、Arbiter三種角色。今天給大家介紹的是Primary與Secondary數(shù)據(jù)同步的內(nèi)部原理。MongoDB副本集架構(gòu)如下所示：

1

1.2、MongoDB Oplog
MongoDB Oplog是MongoDB Primary和Secondary在復(fù)制建立期間和建立完成之后的復(fù)制介質(zhì)，就是Primary中所有的寫(xiě)入操作都會(huì)記錄到MongoDB Oplog中，然后從庫(kù)會(huì)來(lái)主庫(kù)一直拉取Oplog并應(yīng)用到自己的數(shù)據(jù)庫(kù)中。這里的Oplog是MongoDB local數(shù)據(jù)庫(kù)的一個(gè)集合，它是Capped collection，通俗意思就是它是固定大小，循環(huán)使用的。如下圖：

2

MongoDB Oplog中的內(nèi)容及字段介紹：

{
"ts" : Timestamp(1446011584, 2),
"h" : NumberLong("1687359108795812092"),
"v" : 2,
"op" : "i",
"ns" : "test.nosql",
"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }
}

ts： 操作時(shí)間，當(dāng)前timestamp + 計(jì)數(shù)器，計(jì)數(shù)器每秒都被重置
h：操作的全局唯一標(biāo)識(shí)
v：oplog版本信息
op：操作類(lèi)型
    i：插入操作
    u：更新操作
    d：刪除操作
    c：執(zhí)行命令（如createDatabase，dropDatabase）
n：空操作，特殊用途
ns：操作針對(duì)的集合
o：操作內(nèi)容，如果是更新操作
o2：操作查詢(xún)條件，僅update操作包含該字段
1.3、MongoDB復(fù)制發(fā)展
MongoDB目前已經(jīng)迭代了很多個(gè)版本，下圖我匯總了目前市面上常用版本中MongoDB在復(fù)制的一些重要改進(jìn)。

3

具體細(xì)節(jié)大家可以參考MongoDB官方Release Note：https://docs.mongodb.com/manual/release-notes/3.6/

2、MongoDB添加從庫(kù)
2.1、添加從庫(kù)命令
MongoDB添加從庫(kù)比較簡(jiǎn)單，在安裝從庫(kù)之后，直接在主庫(kù)執(zhí)行rs.add()或者replSetReconfig命令即可添加，這兩個(gè)命令其實(shí)在最終都調(diào)用replSetReconfig命令執(zhí)行。大家有興趣可以去翻閱MongoDB客戶(hù)端JS代碼。

2.2、具體步驟
然后我們來(lái)看副本集加一個(gè)新從庫(kù)的大致步驟，如下圖，右邊的Secondary是我新加的從庫(kù)。

4

通過(guò)上圖我們可以看到一共有7個(gè)步驟，下面我們看看每一個(gè)步驟MongoDB都做了什么：

1、 主庫(kù)收到添加從庫(kù)命令
2、 主庫(kù)更新副本集配置并與新從庫(kù)建立心跳機(jī)制
3、 從庫(kù)收到主庫(kù)發(fā)送過(guò)來(lái)的心跳消息與主庫(kù)建立心跳
4、 其他從庫(kù)收到主庫(kù)發(fā)來(lái)的新版本副本集配置信息并更新自己的配置
5、 其他從庫(kù)與新從庫(kù)建立心跳機(jī)制
6、 新從庫(kù)收到其他從庫(kù)心跳信息并跟其他從庫(kù)建立心跳機(jī)制
7、 新加的節(jié)點(diǎn)將副本集配置信息更新到local.system.replset集合中，MongoDB會(huì)在一個(gè)循環(huán)中查詢(xún)local.system.replset是否配置了replset 信息，一旦查到相關(guān)信息觸發(fā)開(kāi)啟復(fù)制線(xiàn)程，然后判斷是否需要全量復(fù)制，需要的話(huà)走全量復(fù)制，不需要走增量復(fù)制。
8、 最終同步建立完成

注意：
副本集所有節(jié)點(diǎn)之前都有相互的心跳機(jī)制，每2秒一次，在MongoDB 3.2版本以后我們可以通過(guò)heartbeatIntervalMillis參數(shù)來(lái)控制心跳頻率。

上述過(guò)程大家可以結(jié)合副本集節(jié)點(diǎn)狀態(tài)來(lái)看(rs.status命令)：

STARTUP //在副本集每個(gè)節(jié)點(diǎn)啟動(dòng)的時(shí)候，mongod加載副本集配置信息，然后將狀態(tài)轉(zhuǎn)換為STARTUP2
STARTUP2 //加載配置之后決定是否需要做Initial Sync，需要?jiǎng)t停留在STARTUP2狀態(tài)，不需要?jiǎng)t進(jìn)入RECOVERING狀態(tài)
RECOVERING //處于不可對(duì)外提供讀寫(xiě)的階段，主要在Initial Sync之后追增量數(shù)據(jù)時(shí)候。
3、 MongoDB復(fù)制流程詳解
上面我們知道添加一個(gè)從庫(kù)的大致流程，那我們現(xiàn)在來(lái)看主從數(shù)據(jù)同步的具體細(xì)節(jié)。當(dāng)從庫(kù)加入到副本集的時(shí)候，會(huì)判斷自己是需要Initial Syc（全量同步）還是增量同步。那是通過(guò)什么條件判斷的呢？

3.1、判斷全量同步及增量同步
如果local數(shù)據(jù)庫(kù)中的oplog.rs 集合是空的，則做全量同步。
如果minValid集合里面存儲(chǔ)的是_initialSyncFlag，則做全量同步（用于init sync失敗處理）
如果initialSyncRequested是true，則做全量同步（用于resync命令，resync命令只用于master/slave架構(gòu)，副本集無(wú)法使用）
以上三個(gè)條件有一個(gè)條件滿(mǎn)足就需要做全量同步。

我們可以得出在從庫(kù)最開(kāi)始加入到副本集的時(shí)候，只能先進(jìn)行Initial Sync，下面我們來(lái)看看Initial Sync的具體流程

3.2、全量同步流程(Init sync)
3.2.1、 尋找同步源
這里先說(shuō)明一點(diǎn)，MongoDB默認(rèn)是采取級(jí)聯(lián)復(fù)制的架構(gòu)，就是默認(rèn)不一定選擇主庫(kù)作為自己的同步源，如果不想讓其進(jìn)行級(jí)聯(lián)復(fù)制，可以通過(guò)chainingAllowed參數(shù)來(lái)進(jìn)行控制。在級(jí)聯(lián)復(fù)制的情況下，你也可以通過(guò)replSetSyncFrom命令來(lái)指定你想復(fù)制的同步源。所以這里說(shuō)的同步源其實(shí)相對(duì)于從庫(kù)來(lái)說(shuō)就是它的主庫(kù)。那么同步源的選取流程是怎樣的呢？

MongoDB從庫(kù)會(huì)在副本集其他節(jié)點(diǎn)通過(guò)以下條件篩選符合自己的同步源。

如果設(shè)置了chainingAllowed 為false，那么只能選取主庫(kù)為同步源
找到與自己ping時(shí)間最小的并且數(shù)據(jù)比自己新的節(jié)點(diǎn) （在副本集初始化的時(shí)候，或者新節(jié)點(diǎn)加入副本集的時(shí)候，新節(jié)點(diǎn)對(duì)副本集的其他節(jié)點(diǎn)至少ping兩次）
該同步源與主庫(kù)最新optime做對(duì)比，如果延遲主庫(kù)超過(guò)30s，則不選擇該同步源。
在第一次的過(guò)濾中，首先會(huì)淘汰比自己數(shù)據(jù)還舊的節(jié)點(diǎn)。如果第一次沒(méi)有，那么第二次需要算上這些節(jié)點(diǎn)，防止最后沒(méi)有節(jié)點(diǎn)可以做為同步源了。
最后確認(rèn)該節(jié)點(diǎn)是否被禁止參與選舉，如果是則跳過(guò)該節(jié)點(diǎn)。
通過(guò)上述篩選最后過(guò)濾出來(lái)的節(jié)點(diǎn)作為新的同步源。

其實(shí)MongoDB同步源在除了在Initial Sync和增量復(fù)制 的時(shí)候選定之后呢，并不是一直是穩(wěn)定的，它可能在以下情況下進(jìn)行變更同步源：

ping不通自己的同步源
自己的同步源角色發(fā)生變化
自己的同步源與副本集任意一個(gè)節(jié)點(diǎn)延遲超過(guò)30s
3.2.2、 刪除MongoDB中除local以外的所有數(shù)據(jù)庫(kù)
3.2.3、 拉取主庫(kù)存量數(shù)據(jù)
這里就到了Initial Sync的核心邏輯了，我下面以圖和步驟的方式給大家展現(xiàn)MongoDB在做Initial Sync的具體流程。

5

注：本圖是針對(duì)于MongoDB 3.4之前的版本

同步流程如下：
* 0. Add _initialSyncFlag to minValid collection to tell us to restart initial sync if we crash in the middle of this procedure
* 1. Record start time.（記錄當(dāng)前主庫(kù)最近一次oplog time）
* 2. Clone.
* 3. Set minValid1 to sync target’s latest op time.
* 4. Apply ops from start to minValid1, fetching missing docs as needed.（Apply Oplog 1）
* 5. Set minValid2 to sync target’s latest op time.
* 6. Apply ops from minValid1 to minValid2.（Apply Oplog 2）
* 7. Build indexes.
* 8. Set minValid3 to sync target’s latest op time.
* 9. Apply ops from minValid2 to minValid3.（Apply Oplog 3）
10. Cleanup minValid collection: remove _initialSyncFlag field, set ts to minValid3 OpTime
注：以上步驟直接copy的MongoDB源碼中的注釋。

以上步驟在Mongo 3.4 Initial Sync 有如下改進(jìn)：

在創(chuàng)建的集合的時(shí)候同時(shí)創(chuàng)建了索引（與主庫(kù)一樣），在MongoDB 3.4版本之前只創(chuàng)建_id索引，其他索引等待數(shù)據(jù)copy完成之后進(jìn)行創(chuàng)建。
在創(chuàng)建集合和拷貝數(shù)據(jù)的同時(shí)，也將oplog拷貝到本地local數(shù)據(jù)庫(kù)中，等到數(shù)據(jù)拷貝完成之后，開(kāi)始應(yīng)用本地oplog數(shù)據(jù)。
新增由于網(wǎng)絡(luò)問(wèn)題導(dǎo)致Initial Sync 失敗重試機(jī)制。
在Initial Sync期間發(fā)現(xiàn)collection 重命名了會(huì)重新開(kāi)始Initial Sync。
上述4個(gè)新增特性提升了Initial Sync的效率并且提高了Initial Sync的可靠性，所以大家使用MongoDB最好使用最新版本MongoDB 3.4或者3.6，MongoDB 3.6 更是有一些令人興奮的特性，這里就不在此敘述了。
全量同步完成之后，然后MongoDB會(huì)進(jìn)入到增量同步的流程。

3.3、增量同步流程
上面我們介紹了Initial Sync，就是已經(jīng)把同步源的存量數(shù)據(jù)拿過(guò)來(lái)了，那主庫(kù)后續(xù)寫(xiě)入的數(shù)據(jù)怎么同步過(guò)來(lái)呢？下面還是以圖跟具體的步驟來(lái)給大家介紹：

6

注：這里不一定是Primary，剛剛提到了同步源也可能是Secondary，這里采用Primary主要方便大家理解。

我們可以看到上述有6個(gè)步驟，那每個(gè)步驟具體做的事情如下：

1、 Sencondary 初始化同步完成之后，開(kāi)始增量復(fù)制，通過(guò)produce線(xiàn)程在Primary oplog.rs集合上建立cursor，并且實(shí)時(shí)請(qǐng)求獲取數(shù)據(jù)。
2、 Primary 返回oplog 數(shù)據(jù)給Secondary。
3、 Sencondary 讀取到Primary 發(fā)送過(guò)來(lái)的oplog，將其寫(xiě)入到隊(duì)列中。
4、 Sencondary 的同步線(xiàn)程會(huì)通過(guò)tryPopAndWaitForMore方法一直消費(fèi)隊(duì)列，當(dāng)每次達(dá)到一定的條件之后，條件如下：

總數(shù)據(jù)大于100MB
已經(jīng)取到部分?jǐn)?shù)據(jù)但沒(méi)到100MB，但是目前隊(duì)列沒(méi)數(shù)據(jù)了，這個(gè)時(shí)候會(huì)阻塞等待一秒，如果還沒(méi)有數(shù)據(jù)則本次取數(shù)據(jù)完成。
上述兩個(gè)條件滿(mǎn)足一個(gè)之后，就會(huì)將數(shù)據(jù)給prefetchOps方法處理，prefetchOps方法主要將數(shù)據(jù)以database級(jí)別切分，便于后面多線(xiàn)程寫(xiě)入到數(shù)據(jù)庫(kù)中。如果采用的WiredTiger引擎，那這里是以Docment ID 進(jìn)行切分。

5、 最終將劃分好的數(shù)據(jù)以多線(xiàn)程的方式批量寫(xiě)入到數(shù)據(jù)庫(kù)中（在從庫(kù)批量寫(xiě)入數(shù)據(jù)的時(shí)候MongoDB會(huì)阻塞所有的讀）。
6、 然后再將Queue中的Oplog數(shù)據(jù)寫(xiě)入到Sencondary中的oplog.rs集合中。

4、 MongoDB高可用
上面我們介紹MongoDB復(fù)制的數(shù)據(jù)同步，我們知道除了數(shù)據(jù)同步，復(fù)制還有一個(gè)重要的地方就是高可用，一般的數(shù)據(jù)庫(kù)是需要我們自己去定制方案或者采用第三方的開(kāi)源方案。MongoDB則是自己在內(nèi)部已經(jīng)實(shí)現(xiàn)了高可用方案。下面我就給大家詳細(xì)介紹一下MongoDB的高可用。

4.1、觸發(fā)切換場(chǎng)景
首先我們看那些情況會(huì)觸發(fā)MongoDB執(zhí)行主從切換。

1、 新初始化一套副本集
2、 從庫(kù)不能連接到主庫(kù)（默認(rèn)超過(guò)10s，可通過(guò)heartbeatTimeoutSecs參數(shù)控制），從庫(kù)發(fā)起選舉
3、 主庫(kù)主動(dòng)放棄primary 角色

主動(dòng)執(zhí)行rs.stepdown 命令
主庫(kù)與大部分節(jié)點(diǎn)都無(wú)法通信的情況下
修改副本集配置的時(shí)候（在Mongo 2.6版本會(huì)觸發(fā)，其他版本待確定）
修改以下配置的時(shí)候：

_id
votes
priotity
arbiterOnly
slaveDelay
hidden
buildIndexes
4、 移除從庫(kù)的時(shí)候（在MongoDB 2.6會(huì)觸發(fā)，MongoDB 3.4不會(huì)，其他版本待確定）

4.2、心跳機(jī)制
通過(guò)上面觸發(fā)切換的場(chǎng)景，我們了解到MongoDB的心跳信息是MongoDB判斷對(duì)方是否存活的重要條件，當(dāng)達(dá)到一定的條件時(shí)，MongoDB主庫(kù)或者從庫(kù)就會(huì)觸發(fā)切換。下面我給大家詳細(xì)介紹一下心跳機(jī)制

我們知道MongoDB副本集所有節(jié)點(diǎn)都是相互保持心跳的，然后心跳頻率默認(rèn)是2秒一次，也可以通過(guò)heartbeatIntervalMillis來(lái)進(jìn)行控制。在新節(jié)點(diǎn)加入進(jìn)來(lái)的時(shí)候，副本集中所有的節(jié)點(diǎn)需要與新節(jié)點(diǎn)建立心跳，那心跳信息具體是什么內(nèi)容呢？

心跳信息內(nèi)容：

BSONObjBuilder cmdBuilder;
cmdBuilder.append("replSetHeartbeat", setName);
cmdBuilder.append("v", myCfgVersion);
cmdBuilder.append("pv", 1);
cmdBuilder.append("checkEmpty", checkEmpty);
cmdBuilder.append("from", from);
if (me > -1) {
cmdBuilder.append("fromId", me);
}  
注：上述代碼摘抄MongoDB 源碼中構(gòu)建心跳信息片段。

具體在MongoDB日志中表現(xiàn)如下：

command admin.$cmd command: replSetHeartbeat { replSetHeartbeat: "shard1", v: 21, pv: 1, checkEmpty: false, from: "10.13.32.244:40011", fromId: 3 } ntoreturn:1 keyUpdates:0
那副本集所有節(jié)點(diǎn)默認(rèn)都是每2秒給其他剩余的節(jié)點(diǎn)發(fā)送上述信息，在其他節(jié)點(diǎn)收到信息后會(huì)調(diào)用ReplSetCommand命令來(lái)處理心跳信息，處理完成會(huì)返回如下信息：

        result.append("set", theReplSet->name());
        MemberState currentState = theReplSet->state();
        result.append("state", currentState.s);  // 當(dāng)前節(jié)點(diǎn)狀態(tài)
        if (currentState == MemberState::RS_PRIMARY) {
            result.appendDate("electionTime", theReplSet->getElectionTime().asDate());
        }
        result.append("e", theReplSet->iAmElectable());  //是否可以參與選舉
        result.append("hbmsg", theReplSet->hbmsg());
        result.append("time", (long long) time(0));
        result.appendDate("opTime", theReplSet->lastOpTimeWritten.asDate());
        const Member *syncTarget = replset::BackgroundSync::get()->getSyncTarget();
        if (syncTarget) {
            result.append("syncingTo", syncTarget->fullName());
        }

        int v = theReplSet->config().version;
        result.append("v", v);
        if( v > cmdObj["v"].Int() )
            result << "config" <config().asBson();
注：以上信息是正常情況下返回的，還有一些不正常的處理場(chǎng)景，這里就不一一細(xì)說(shuō)了。

4.3、切換流程
前面我們了解了觸發(fā)切換的場(chǎng)景以及MongoDB副本集節(jié)點(diǎn)之前的心跳機(jī)制。下面我們來(lái)看切換的具體流程：
1、從庫(kù)無(wú)法連接到主庫(kù)，或者主庫(kù)放棄Primary角色。
2、從庫(kù)會(huì)根據(jù)心跳消息獲取當(dāng)前該節(jié)點(diǎn)的角色并與之前進(jìn)行對(duì)比
3、如果角色發(fā)生改變就開(kāi)始執(zhí)行msgCheckNewState方法
4、在msgCheckNewState 方法中最終調(diào)用electSelf 方法（會(huì)有一些判斷來(lái)決定是否最終調(diào)用electSelf方法）
5、electSelf 方法最終向副本集其他節(jié)點(diǎn)發(fā)送replSetElect命令來(lái)請(qǐng)求投票。
命令如下：

BSONObj electCmd = BSON(
"replSetElect" << 1 <<
"set" << rs.name() <<
"who" << me.fullName() <<
"whoid" << me.hbinfo().id() <<
"cfgver" <version <<
"round" << OID::gen() /* this is just for diagnostics */
);

具體日志表現(xiàn)如下：

2017-12-14T10:13:26.917+0800 [conn27669] run command admin.$cmd { replSetElect: 1, set: “shard1″, who: “10.13.32.244:40015″, whoid: 4, cfgver: 27, round: ObjectId(’5a31de4601fbde95ae38b4d2′) }

6、其他副本集收到replSetElect會(huì)對(duì)比cfgver信息，會(huì)確認(rèn)發(fā)送該命令的節(jié)點(diǎn)是否在副本集中，確認(rèn)該節(jié)點(diǎn)的優(yōu)先級(jí)是否是該副本集所有節(jié)點(diǎn)中優(yōu)先級(jí)最大的。最后滿(mǎn)足條件才會(huì)給該節(jié)點(diǎn)發(fā)送投票信息。
7、發(fā)起投票的節(jié)點(diǎn)最后會(huì)統(tǒng)計(jì)所得票數(shù)大于副本集可參與投票數(shù)量的一半，則搶占成功，成為新的Primary。
8、其他從庫(kù)如果發(fā)現(xiàn)自己的同步源角色發(fā)生變化，則會(huì)觸發(fā)重新選取同步源。

4.4、Rollback
我們知道在發(fā)生切換的時(shí)候是有可能造成數(shù)據(jù)丟失的，主要是因?yàn)橹鲙?kù)宕機(jī)，但是新寫(xiě)入的數(shù)據(jù)還沒(méi)有來(lái)得及同步到從庫(kù)中，這個(gè)時(shí)候就會(huì)發(fā)生數(shù)據(jù)丟失的情況。

那針對(duì)這種情況，MongoDB增加了回滾的機(jī)制。在主庫(kù)恢復(fù)后重新加入到復(fù)制集中，這個(gè)時(shí)候老主庫(kù)會(huì)與同步源對(duì)比oplog信息，這時(shí)候分為以下兩種情況：
1、 在同步源中沒(méi)有找到比老主庫(kù)新的oplog信息。
2、 同步源最新一條oplog信息跟老主庫(kù)的optime和oplog的hash內(nèi)容不同。

針對(duì)上述兩種情況MongoDB會(huì)進(jìn)行回滾，回滾的過(guò)程就是逆向?qū)Ρ萶plog的信息，直到在老主庫(kù)和同步源中找到對(duì)應(yīng)的oplog，然后將這期間的oplog全部記錄到rollback目錄里的文件中，如果但是出現(xiàn)以下情況會(huì)終止回滾：

對(duì)比老主庫(kù)的optime和同步源的optime，如果超過(guò)了30分鐘，那么放棄回滾。
在回滾的過(guò)程中，如果發(fā)現(xiàn)單條oplog超過(guò)512M，則放棄回滾。
如果有dropDatabase操作，則放棄回滾。
最終生成的回滾記錄超過(guò)300M，也會(huì)放棄回滾。
上述我們已經(jīng)知道了MongoDB的回滾原理，但是我們?cè)谏�產(chǎn)環(huán)境中怎么避免回滾操作呢，因?yàn)楫吘够貪L操作很麻煩，而且針對(duì)有時(shí)序性的業(yè)務(wù)邏輯也是不可接受的。那MongoDB也提供了對(duì)應(yīng)的方案，就是WriteConcern，這里就不細(xì)說(shuō)了，有興趣的朋友可以仔細(xì)了解。其實(shí)這也是在CAP中做出一個(gè)選擇。

5、 MongoDB復(fù)制總結(jié)
MongoDB復(fù)制內(nèi)部原理已經(jīng)給大家介紹完畢，以上其實(shí)還涉及很多細(xì)節(jié)沒(méi)能一一列出。大家有興趣可以自己去整理。這里還需要說(shuō)明一點(diǎn)就是MongoDB版本迭代速度比較快，所以本文只針對(duì)于MongoDB 2.6 到MongoDB 3.4 版本，不過(guò)在某些版本可能會(huì)存在一些細(xì)節(jié)的變動(dòng)，但是大體上的邏輯還是沒(méi)有改變。最后大家如果有什么問(wèn)題，也可以與我聯(lián)系。