摘要：申明本文由筆者首發(fā)于深入淺出復(fù)制中文社區(qū)深入淺出復(fù)制由于自己開了，所以將之前比較好的文章挪過來便于大家瀏覽。新增由于網(wǎng)絡(luò)問題導(dǎo)致失敗重試機(jī)制。

本文由筆者首發(fā)于
InfoQ：《深入淺出MongoDB復(fù)制》
MongoDB中文社區(qū)：《深入淺出MongoDB復(fù)制》

由于自己開了blog，所以將之前比較好的文章挪過來便于大家瀏覽。

筆者最近在生產(chǎn)環(huán)境中遇到許多復(fù)制相關(guān)問題，查閱網(wǎng)上資料發(fā)現(xiàn)官方文檔雖然系統(tǒng)但是不夠有深度，網(wǎng)上部分深度文章則直接以源碼展示，不利于大家了解。所以本文則是結(jié)合前兩者最終給讀者以簡單的方式展現(xiàn)MongoDB復(fù)制的整個(gè)架構(gòu)。本文分為以下5個(gè)步驟：

MongoDB復(fù)制簡介

MongoDB添加從庫

MongoDB復(fù)制流程詳解

MongoDB高可用

MongoDB復(fù)制總結(jié)

本章節(jié)首先會給大家簡單介紹一些MongoDB復(fù)制的一些基本概念，便于大家對后面內(nèi)容的理解。

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

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

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)識
    v：oplog版本信息
    op：操作類型
        i：插入操作
        u：更新操作
        d：刪除操作
        c：執(zhí)行命令（如createDatabase，dropDatabase）
    n：空操作，特殊用途
    ns：操作針對的集合
    o：操作內(nèi)容，如果是更新操作
    o2：操作查詢條件，僅update操作包含該字段

MongoDB目前已經(jīng)迭代了很多個(gè)版本，下圖我匯總了目前市面上常用版本中MongoDB在復(fù)制的一些重要改進(jìn)。

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

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

然后我們來看副本集加一個(gè)新從庫的大致步驟，如下圖，右邊的Secondary是我新加的從庫。

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

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

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

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

STARTUP //在副本集每個(gè)節(jié)點(diǎn)啟動的時(shí)候，mongod加載副本集配置信息，然后將狀態(tài)轉(zhuǎn)換為STARTUP2

STARTUP2 //加載配置之后決定是否需要做Initial Sync，需要則停留在STARTUP2狀態(tài)，不需要則進(jìn)入RECOVERING狀態(tài)

RECOVERING //處于不可對外提供讀寫的階段，主要在Initial Sync之后追增量數(shù)據(jù)時(shí)候。

上面我們知道添加一個(gè)從庫的大致流程，那我們現(xiàn)在來看主從數(shù)據(jù)同步的具體細(xì)節(jié)。當(dāng)從庫加入到副本集的時(shí)候，會判斷自己是需要Initial Syc（全量同步）還是增量同步。那是通過什么條件判斷的呢？

如果local數(shù)據(jù)庫中的oplog.rs 集合是空的，則做全量同步。

如果minValid集合里面存儲的是_initialSyncFlag，則做全量同步（用于init sync失敗處理）

如果initialSyncRequested是true，則做全量同步（用于resync命令，resync命令只用于master/slave架構(gòu)，副本集無法使用）

以上三個(gè)條件有一個(gè)條件滿足就需要做全量同步。

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

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

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

如果設(shè)置了chainingAllowed 為false，那么只能選取主庫為同步源

找到與自己ping時(shí)間最小的并且數(shù)據(jù)比自己新的節(jié)點(diǎn) （在副本集初始化的時(shí)候，或者新節(jié)點(diǎn)加入副本集的時(shí)候，新節(jié)點(diǎn)對副本集的其他節(jié)點(diǎn)至少ping兩次）

該同步源與主庫最新optime做對比，如果延遲主庫超過30s，則不選擇該同步源。

在第一次的過濾中，首先會淘汰比自己數(shù)據(jù)還舊的節(jié)點(diǎn)。如果第一次沒有，那么第二次需要算上這些節(jié)點(diǎn)，防止最后沒有節(jié)點(diǎn)可以做為同步源了。

最后確認(rèn)該節(jié)點(diǎn)是否被禁止參與選舉，如果是則跳過該節(jié)點(diǎn)。

通過上述篩選最后過濾出來的節(jié)點(diǎn)作為新的同步源。

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

ping不通自己的同步源

自己的同步源角色發(fā)生變化

自己的同步源與副本集任意一個(gè)節(jié)點(diǎn)延遲超過30s

這里就到了Initial Sync的核心邏輯了，我下面以圖和步驟的方式給大家展現(xiàn)MongoDB在做Initial Sync的具體流程。

注：本圖是針對于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)前主庫最近一次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)建了索引（與主庫一樣），在MongoDB 3.4版本之前只創(chuàng)建_id索引，其他索引等待數(shù)據(jù)copy完成之后進(jìn)行創(chuàng)建。

在創(chuàng)建集合和拷貝數(shù)據(jù)的同時(shí)，也將oplog拷貝到本地local數(shù)據(jù)庫中，等到數(shù)據(jù)拷貝完成之后，開始應(yīng)用本地oplog數(shù)據(jù)。

新增由于網(wǎng)絡(luò)問題導(dǎo)致Initial Sync 失敗重試機(jī)制。

在Initial Sync期間發(fā)現(xiàn)collection 重命名了會重新開始Initial Sync。

上述4個(gè)新增特性提升了Initial Sync的效率并且提高了Initial Sync的可靠性，所以大家使用MongoDB最好使用最新版本MongoDB 3.4或者3.6，MongoDB 3.6 更是有一些令人興奮的特性，這里就不在此敘述了。
全量同步完成之后，然后MongoDB會進(jìn)入到增量同步的流程。

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

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

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

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

總數(shù)據(jù)大于100MB

已經(jīng)取到部分?jǐn)?shù)據(jù)但沒到100MB，但是目前隊(duì)列沒數(shù)據(jù)了，這個(gè)時(shí)候會阻塞等待一秒，如果還沒有數(shù)據(jù)則本次取數(shù)據(jù)完成。

上述兩個(gè)條件滿足一個(gè)之后，就會將數(shù)據(jù)給prefetchOps方法處理，prefetchOps方法主要將數(shù)據(jù)以database級別切分，便于后面多線程寫入到數(shù)據(jù)庫中。如果采用的WiredTiger引擎，那這里是以Docment ID 進(jìn)行切分。

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

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

首先我們看那些情況會觸發(fā)MongoDB執(zhí)行主從切換。

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

主動執(zhí)行rs.stepdown 命令

主庫與大部分節(jié)點(diǎn)都無法通信的情況下

修改副本集配置的時(shí)候（在Mongo 2.6版本會觸發(fā)，其他版本待確定）

修改以下配置的時(shí)候：

_id

votes

priotity

arbiterOnly

slaveDelay

hidden

buildIndexes

4、 移除從庫的時(shí)候（在MongoDB 2.6會觸發(fā)，MongoDB 3.4不會，其他版本待確定）

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

我們知道MongoDB副本集所有節(jié)點(diǎn)都是相互保持心跳的，然后心跳頻率默認(rèn)是2秒一次，也可以通過heartbeatIntervalMillis來進(jìn)行控制。在新節(jié)點(diǎn)加入進(jìn)來的時(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)收到信息后會調(diào)用ReplSetCommand命令來處理心跳信息，處理完成會返回如下信息：

            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" 
注：以上信息是正常情況下返回的，還有一些不正常的處理場景，這里就不一一細(xì)說了。
4.3、切換流程
前面我們了解了觸發(fā)切換的場景以及MongoDB副本集節(jié)點(diǎn)之前的心跳機(jī)制。下面我們來看切換的具體流程：
1、從庫無法連接到主庫，或者主庫放棄Primary角色。
2、從庫會根據(jù)心跳消息獲取當(dāng)前該節(jié)點(diǎn)的角色并與之前進(jìn)行對比
3、如果角色發(fā)生改變就開始執(zhí)行msgCheckNewState方法
4、在msgCheckNewState 方法中最終調(diào)用electSelf 方法（會有一些判斷來決定是否最終調(diào)用electSelf方法）
5、electSelf 方法最終向副本集其他節(jié)點(diǎn)發(fā)送replSetElect命令來請求投票。
命令如下：
BSONObj electCmd = BSON(
                       "replSetElect" << 1 <<
                       "set" << rs.name() <<
                       "who" << me.fullName() <<
                       "whoid" << me.hbinfo().id() <<
                       "cfgver" 
具體日志表現(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會對比cfgver信息，會確認(rèn)發(fā)送該命令的節(jié)點(diǎn)是否在副本集中，確認(rèn)該節(jié)點(diǎn)的優(yōu)先級是否是該副本集所有節(jié)點(diǎn)中優(yōu)先級最大的。最后滿足條件才會給該節(jié)點(diǎn)發(fā)送投票信息。
7、發(fā)起投票的節(jié)點(diǎn)最后會統(tǒng)計(jì)所得票數(shù)大于副本集可參與投票數(shù)量的一半，則搶占成功，成為新的Primary。
8、其他從庫如果發(fā)現(xiàn)自己的同步源角色發(fā)生變化，則會觸發(fā)重新選取同步源。
4.4、Rollback
我們知道在發(fā)生切換的時(shí)候是有可能造成數(shù)據(jù)丟失的，主要是因?yàn)橹鲙戾礄C(jī)，但是新寫入的數(shù)據(jù)還沒有來得及同步到從庫中，這個(gè)時(shí)候就會發(fā)生數(shù)據(jù)丟失的情況。
那針對這種情況，MongoDB增加了回滾的機(jī)制。在主庫恢復(fù)后重新加入到復(fù)制集中，這個(gè)時(shí)候老主庫會與同步源對比oplog信息，這時(shí)候分為以下兩種情況：
1、    在同步源中沒有找到比老主庫新的oplog信息。
2、    同步源最新一條oplog信息跟老主庫的optime和oplog的hash內(nèi)容不同。
針對上述兩種情況MongoDB會進(jìn)行回滾，回滾的過程就是逆向?qū)Ρ萶plog的信息，直到在老主庫和同步源中找到對應(yīng)的oplog，然后將這期間的oplog全部記錄到rollback目錄里的文件中，如果但是出現(xiàn)以下情況會終止回滾：

對比老主庫的optime和同步源的optime，如果超過了30分鐘，那么放棄回滾。
在回滾的過程中，如果發(fā)現(xiàn)單條oplog超過512M，則放棄回滾。
如果有dropDatabase操作，則放棄回滾。
最終生成的回滾記錄超過300M，也會放棄回滾。

上述我們已經(jīng)知道了MongoDB的回滾原理，但是我們在生產(chǎn)環(huán)境中怎么避免回滾操作呢，因?yàn)楫吘够貪L操作很麻煩，而且針對有時(shí)序性的業(yè)務(wù)邏輯也是不可接受的。那MongoDB也提供了對應(yīng)的方案，就是WriteConcern，這里就不細(xì)說了，有興趣的朋友可以仔細(xì)了解。其實(shí)這也是在CAP中做出一個(gè)選擇。
5、    MongoDB復(fù)制總結(jié)
MongoDB復(fù)制內(nèi)部原理已經(jīng)給大家介紹完畢，以上其實(shí)還涉及很多細(xì)節(jié)沒能一一列出。大家有興趣可以自己去整理。這里還需要說明一點(diǎn)就是MongoDB版本迭代速度比較快，所以本文只針對于MongoDB 2.6 到MongoDB 3.4 版本，不過在某些版本可能會存在一些細(xì)節(jié)的變動，但是大體上的邏輯還是沒有改變。最后大家如果有什么問題，也可以與我聯(lián)系。