MongoDB復制集數據同步流程

Mongodb復制集里的Secondary會從Primary上同步數據，以保持副本集所有節點的數據保持一致，數據同步主要包含2個過程：

1. initial sync
2. replication （oplog sync）

先通過init sync同步全量數據，再通過replication不斷重放Primary上的oplog同步增量數據。

initial sync

Secondary啟動后，如果滿足以下條件之一，會先進行initial sync

1. Secondary上oplog為空，比如新加入的空節點
2. local.replset.minvalid集合里_initialSyncFlag標記被設置。當initial sync開始時，同步線程會設置該標記，當initial sync結束時清除該標記，故如果initial sync過程中途失敗，節點重啟后發現該標記被設置，就知道應該重新進行initial sync。
3. BackgroundSync::_initialSyncRequestedFlag被設置。當向節點發送resync命令時，該標記會被設置，此時會強制重新initial sync。

initial sync同步流程

1. minValid集合設置_initialSyncFlag
2. 獲取同步源當前最新的oplog時間戳t0
3. 從同步源Clone所有的集合數據
4. 獲取同步源最新的oplog時間戳t1
5. 同步t0~t1所有的oplog
6. 獲取同步源最新的oplog時間戳t2
7. 同步t1~t2所有的oplog
8. 從同步源讀取index信息，并建立索引
9. 獲取同步源最新的oplog時間戳t3
10. 同步t2~t3所有的oplog
11. minValid集合清除_initialSyncFlag，initial sync結束

replication (sync oplog)

initial sync結束后，Secondary會建立到Primary上local.oplog.rs的tailable cursor，不斷從Primary上獲取新寫入的oplog，并應用到自身。

Tailable cursor每次會獲取到一批oplog，Secondary采用多線程重放oplog以提高效率，通過將oplog按照所屬的namespace進行分組，劃分到多個線程里，保證同一個namespace的所有操作都由一個線程來replay，以保證統一namespace的操作時序跟primary上保持一致（如果引擎支持文檔鎖，只需保證同一個文檔的操作時序與primary一致即可）。

同步場景分析

1. 副本集初始化

初始化選出Primary后，此時Secondary上無有效數據，oplog是空的，會先進行initial sync，然后不斷的應用新的oplog

2. 新成員加入

因新成員上無有效數據，oplog是空的，會先進行initial sync，然后不斷的應用新的oplog

3. 有數據的節點加入

有數據的節點加入有如下情況：

1. 該節點與副本集其他節點斷開連接，一段時間后恢復
2. 該節點從副本集移除（處于REMOVED）狀態，通過replSetReconfig命令將其重新加入
3. 其他? 因同一個副本集的成員replSetName配置必須相同，除非有誤配置，應該不會有其他場景

此時，如果該節點最新的oplog時間戳，比所有節點最舊的oplog時間戳還要小，該節點將找不到同步源，會一直處于RECOVERING而不能服務；反之，如果能找到同步源，則直接進入replication階段，不斷的應用新的oplog。

因oplog太舊而處于RECOVERING的節點目前無法自動恢復，需人工介入處理（故設置合理的oplog大小非常重要），最簡單的方式是發送resync命令，讓該節點重新進行initial sync。

參考資料

1. Replica Set Data Synchronization
2. Resync a Member of a Replica Set
3. Create tailable cursor

作者簡介

張友東，就職于阿里云飛天技術部，主要關注分布式存儲、Nosql等技術領域，參與 TFS（淘寶分布式文件系統）、 AliCloudDB for Redis等項目的開發工作，歡迎交流