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等项目的开发工作,欢迎交流。

发表评论