深入淺出MongoDB 複製

                                    

申明

本文由筆者首發於
InfoQ:《深入淺出MongoDB複製》
MongoDB中文社群:《深入淺出MongoDB複製》

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

綜述

筆者最近在生產環境中遇到許多複製相關問題,查閱網上資料發現官方文件雖然系統但是不夠有深度,網上部分深度文章則直接以原始碼展示,不利於大家瞭解。所以本文則是結合前兩者最終給讀者以簡單的方式展現MongoDB複製的整個架構。本文分為以下5個步驟:

MongoDB複製簡介
MongoDB新增從庫
MongoDB複製流程詳解
MongoDB高可用
MongoDB複製總結

1、MongoDB複製簡介

本章節首先會給大家簡單介紹一些MongoDB複製的一些基本概念,便於大家對後面內容的理解。

1.1、基本介紹

MongoDB有副本集及主從複製兩種模式,今天給大家介紹的是副本集模式,因為主從模式在MongoDB 3.6也徹底廢棄不使用了。MongoDB副本集有Primary、Secondary、Arbiter三種角色。今天給大家介紹的是Primary與Secondary資料同步的內部原理。MongoDB副本集架構如下所示:

1.2、MongoDB Oplog

MongoDB Oplog是MongoDB Primary和Secondary在複製建立期間和建立完成之後的複製介質,就是Primary中所有的寫入操作都會記錄到MongoDB Oplog中,然後從庫會來主庫一直拉取Oplog並應用到自己的資料庫中。這裡的Oplog是MongoDB local資料庫的一個集合,它是Capped collection,通俗意思就是它是固定大小,迴圈使用的。如下圖:

MongoDB Oplog中的內容及欄位介紹:

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

    ts: 操作時間,當前timestamp   計數器,計數器每秒都被重置
    h:操作的全域性唯一標識
    v:oplog版本資訊
    op:操作型別
        i:插入操作
        u:更新操作
        d:刪除操作
        c:執行命令(如createDatabase,dropDatabase)
    n:空操作,特殊用途
    ns:操作針對的集合
    o:操作內容,如果是更新操作
    o2:操作查詢條件,僅update操作包含該欄位

1.3、MongoDB複製發展

MongoDB目前已經迭代了很多個版本,下圖我彙總了目前市面上常用版本中MongoDB在複製的一些重要改進。

具體細節大家可以參考MongoDB官方Release Note:https://docs.mongodb.com/manu…

2、MongoDB新增從庫

2.1、新增從庫命令

MongoDB新增從庫比較簡單,在安裝從庫之後,直接在主庫執行rs.add()或者replSetReconfig命令即可新增,這兩個命令其實在最終都呼叫replSetReconfig命令執行。大家有興趣可以去翻閱MongoDB客戶端JS程式碼。

2.2、具體步驟

然後我們來看副本集加一個新從庫的大致步驟,如下圖,右邊的Secondary是我新加的從庫。

通過上圖我們可以看到一共有7個步驟,下面我們看看每一個步驟MongoDB都做了什麼:

1、 主庫收到新增從庫命令
2、 主庫更新副本集配置並與新從庫建立心跳機制
3、 從庫收到主庫傳送過來的心跳訊息與主庫建立心跳
4、 其他從庫收到主庫發來的新版本副本集配置資訊並更新自己的配置
5、 其他從庫與新從庫建立心跳機制
6、 新從庫收到其他從庫心跳資訊並跟其他從庫建立心跳機制
7、 新加的節點將副本集配置資訊更新到local.system.replset集合中,MongoDB會在一個迴圈中查詢local.system.replset是否配置了replset 資訊,一旦查到相關資訊觸發開啟複製執行緒,然後判斷是否需要全量複製,需要的話走全量複製,不需要走增量複製。
8、 最終同步建立完成

注意:

副本集所有節點之前都有相互的心跳機制,每2秒一次,在MongoDB 3.2版本以後我們可以通過heartbeatIntervalMillis引數來控制心跳頻率。

上述過程大家可以結合副本集節點狀態來看(rs.status命令):

STARTUP //在副本集每個節點啟動的時候,mongod載入副本集配置資訊,然後將狀態轉換為STARTUP2
STARTUP2 //載入配置之後決定是否需要做Initial Sync,需要則停留在STARTUP2狀態,不需要則進入RECOVERING狀態
RECOVERING //處於不可對外提供讀寫的階段,主要在Initial Sync之後追增量資料時候。

3、 MongoDB複製流程詳解

上面我們知道新增一個從庫的大致流程,那我們現在來看主從資料同步的具體細節。當從庫加入到副本集的時候,會判斷自己是需要Initial Syc(全量同步)還是增量同步。那是通過什麼條件判斷的呢?

3.1、判斷全量同步及增量同步

如果local資料庫中的oplog.rs 集合是空的,則做全量同步。
如果minValid集合裡面儲存的是_initialSyncFlag,則做全量同步(用於init sync失敗處理)
如果initialSyncRequested是true,則做全量同步(用於resync命令,resync命令只用於master/slave架構,副本集無法使用)

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

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

3.2、全量同步流程(Init sync)

3.2.1、 尋找同步源

這裡先說明一點,MongoDB預設是採取級聯複製的架構,就是預設不一定選擇主庫作為自己的同步源,如果不想讓其進行級聯複製,可以通過chainingAllowed引數來進行控制。在級聯複製的情況下,你也可以通過replSetSyncFrom命令來指定你想複製的同步源。所以這裡說的同步源其實相對於從庫來說就是它的主庫。那麼同步源的選取流程是怎樣的呢?

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

如果設定了chainingAllowed 為false,那麼只能選取主庫為同步源
找到與自己ping時間最小的並且資料比自己新的節點 (在副本集初始化的時候,或者新節點加入副本集的時候,新節點對副本集的其他節點至少ping兩次)
該同步源與主庫最新optime做對比,如果延遲主庫超過30s,則不選擇該同步源。
在第一次的過濾中,首先會淘汰比自己資料還舊的節點。如果第一次沒有,那麼第二次需要算上這些節點,防止最後沒有節點可以做為同步源了。
最後確認該節點是否被禁止參與選舉,如果是則跳過該節點。

通過上述篩選最後過濾出來的節點作為新的同步源。

其實MongoDB同步源在除了在Initial Sync和增量複製 的時候選定之後呢,並不是一直是穩定的,它可能在以下情況下進行變更同步源:

ping不通自己的同步源
自己的同步源角色發生變化
自己的同步源與副本集任意一個節點延遲超過30s

3.2.2、 刪除MongoDB中除local以外的所有資料庫

3.2.3、 拉取主庫存量資料

這裡就到了Initial Sync的核心邏輯了,我下面以圖和步驟的方式給大家展現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.(記錄當前主庫最近一次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 有如下改進:

在建立的集合的時候同時建立了索引(與主庫一樣),在MongoDB 3.4版本之前只建立_id索引,其他索引等待資料copy完成之後進行建立。
在建立集合和拷貝資料的同時,也將oplog拷貝到本地local資料庫中,等到資料拷貝完成之後,開始應用本地oplog資料。
新增由於網路問題導致Initial Sync 失敗重試機制。
在Initial Sync期間發現collection 重新命名了會重新開始Initial Sync。

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

3.3、增量同步流程

上面我們介紹了Initial Sync,就是已經把同步源的存量資料拿過來了,那主庫後續寫入的資料怎麼同步過來呢?下面還是以圖跟具體的步驟來給大家介紹:

注:這裡不一定是Primary,剛剛提到了同步源也可能是Secondary,這裡採用Primary主要方便大家理解。

我們可以看到上述有6個步驟,那每個步驟具體做的事情如下:

1、 Sencondary 初始化同步完成之後,開始增量複製,通過produce執行緒在Primary oplog.rs集合上建立cursor,並且實時請求獲取資料。
2、 Primary 返回oplog 資料給Secondary。
3、 Sencondary 讀取到Primary 傳送過來的oplog,將其寫入到佇列中。
4、 Sencondary 的同步執行緒會通過tryPopAndWaitForMore方法一直消費佇列,當每次達到一定的條件之後,條件如下:

總資料大於100MB
已經取到部分資料但沒到100MB,但是目前佇列沒資料了,這個時候會阻塞等待一秒,如果還沒有資料則本次取資料完成。

上述兩個條件滿足一個之後,就會將資料給prefetchOps方法處理,prefetchOps方法主要將資料以database級別切分,便於後面多執行緒寫入到資料庫中。如果採用的WiredTiger引擎,那這裡是以Docment ID 進行切分。

5、 最終將劃分好的資料以多執行緒的方式批量寫入到資料庫中(在從庫批量寫入資料的時候MongoDB會阻塞所有的讀)。
6、 然後再將Queue中的Oplog資料寫入到Sencondary中的oplog.rs集合中。

4、 MongoDB高可用

上面我們介紹MongoDB複製的資料同步,我們知道除了資料同步,複製還有一個重要的地方就是高可用,一般的資料庫是需要我們自己去定製方案或者採用第三方的開源方案。MongoDB則是自己在內部已經實現了高可用方案。下面我就給大家詳細介紹一下MongoDB的高可用。

4.1、觸發切換場景

首先我們看那些情況會觸發MongoDB執行主從切換。

1、 新初始化一套副本集
2、 從庫不能連線到主庫(預設超過10s,可通過heartbeatTimeoutSecs引數控制),從庫發起選舉
3、 主庫主動放棄primary 角色

主動執行rs.stepdown 命令
主庫與大部分節點都無法通訊的情況下
修改副本集配置的時候(在Mongo 2.6版本會觸發,其他版本待確定)

修改以下配置的時候:

_id
votes
priotity
arbiterOnly
slaveDelay
hidden
buildIndexes

4、 移除從庫的時候(在MongoDB 2.6會觸發,MongoDB 3.4不會,其他版本待確定)

4.2、心跳機制

通過上面觸發切換的場景,我們瞭解到MongoDB的心跳資訊是MongoDB判斷對方是否存活的重要條件,當達到一定的條件時,MongoDB主庫或者從庫就會觸發切換。下面我給大家詳細介紹一下心跳機制

我們知道MongoDB副本集所有節點都是相互保持心跳的,然後心跳頻率預設是2秒一次,也可以通過heartbeatIntervalMillis來進行控制。在新節點加入進來的時候,副本集中所有的節點需要與新節點建立心跳,那心跳資訊具體是什麼內容呢?

心跳資訊內容:

    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 原始碼中構建心跳資訊片段。

具體在MongoDB日誌中表現如下:

    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

那副本集所有節點預設都是每2秒給其他剩餘的節點傳送上述資訊,在其他節點收到資訊後會呼叫ReplSetCommand命令來處理心跳資訊,處理完成會返回如下資訊:

            result.append("set", theReplSet->name());
            MemberState currentState = theReplSet->state();
            result.append("state", currentState.s);  // 當前節點狀態
            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();

注:以上資訊是正常情況下返回的,還有一些不正常的處理場景,這裡就不一一細說了。

4.3、切換流程

前面我們瞭解了觸發切換的場景以及MongoDB副本集節點之前的心跳機制。下面我們來看切換的具體流程:
1、從庫無法連線到主庫,或者主庫放棄Primary角色。
2、從庫會根據心跳訊息獲取當前該節點的角色並與之前進行對比
3、如果角色發生改變就開始執行msgCheckNewState方法
4、在msgCheckNewState 方法中最終呼叫electSelf 方法(會有一些判斷來決定是否最終呼叫electSelf方法)
5、electSelf 方法最終向副本集其他節點傳送replSetElect命令來請求投票。
命令如下:

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 */
                   );

具體日誌表現如下:

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資訊,會確認傳送該命令的節點是否在副本集中,確認該節點的優先順序是否是該副本集所有節點中優先順序最大的。最後滿足條件才會給該節點傳送投票資訊。
7、發起投票的節點最後會統計所得票數大於副本集可參與投票數量的一半,則搶佔成功,成為新的Primary。
8、其他從庫如果發現自己的同步源角色發生變化,則會觸發重新選取同步源。

4.4、Rollback

我們知道在發生切換的時候是有可能造成資料丟失的,主要是因為主庫宕機,但是新寫入的資料還沒有來得及同步到從庫中,這個時候就會發生資料丟失的情況。

那針對這種情況,MongoDB增加了回滾的機制。在主庫恢復後重新加入到複製集中,這個時候老主庫會與同步源對比oplog資訊,這時候分為以下兩種情況:
1、 在同步源中沒有找到比老主庫新的oplog資訊。
2、 同步源最新一條oplog資訊跟老主庫的optime和oplog的hash內容不同。

針對上述兩種情況MongoDB會進行回滾,回滾的過程就是逆向對比oplog的資訊,直到在老主庫和同步源中找到對應的oplog,然後將這期間的oplog全部記錄到rollback目錄裡的檔案中,如果但是出現以下情況會終止回滾:

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

上述我們已經知道了MongoDB的回滾原理,但是我們在生產環境中怎麼避免回滾操作呢,因為畢竟回滾操作很麻煩,而且針對有時序性的業務邏輯也是不可接受的。那MongoDB也提供了對應的方案,就是WriteConcern,這裡就不細說了,有興趣的朋友可以仔細瞭解。其實這也是在CAP中做出一個選擇。

5、 MongoDB複製總結

MongoDB複製內部原理已經給大家介紹完畢,以上其實還涉及很多細節沒能一一列出。大家有興趣可以自己去整理。這裡還需要說明一點就是MongoDB版本迭代速度比較快,所以本文只針對於MongoDB 2.6 到MongoDB 3.4 版本,不過在某些版本可能會存在一些細節的變動,但是大體上的邏輯還是沒有改變。最後大家如果有什麼問題,也可以與我聯絡。

關聯文章