本文翻译自mongodb官方文档https://docs.[mongodb](https://www.cosmozhu.fun/archives/tag/mongodb).com/v4.0/core/replica-set-sync/
为了维护共享复制集的最新节点，复制集的次要成员节点将同步或复写其他成员节点的数据。MongoDB用了两种方式做数据同步：用全量数据初始化节点，用增量数据复写到节点。
初始化数据同步
初始化数据同步是从一个源节点同步全量数据到目标节点。
处理过程
当MongoDB执行初始化数据同步时会进行两步操作：
- 克隆源节点除了local的所有数据库。
mongod进程会扫描每个数据库的每个集合，并将全量数据插入到目标节点中。
在版本3.4中的变更：在赋值每个集合的文档时，初始化数据同步会构建所有的集合索引。在早期MongoDB版本中，此阶段仅构建_id的索引。
在版本3.4中的变更：初始化数据同步时会在复制数据期间拉取源节点oplog新增加的记录。确保目标成员节点在local数据库中有足够的磁盘空间来临时存储这些操作记录。
- 在目标节点中应用在执行第1步时产生的增量变更。
mongod使用从源节点获取的oplog来更新自己的数据集，然后变更复制集的状态。
初始化数据同步完成后，目标节点的状态从STARTUP2变成了SECONDARY。
容错能力
为了从瞬态网络或者操作故障中恢复，初始化数据同步有内建的重试机制。
在版本3.4中的变更：MongoDB 3.4改进了初始化数据同步重试逻辑，以更灵活地应对网络上的间歇性故障。
复写
次要成员节点在初始化数据同步完成后就一直不断的复写数据。次要成员节点从他们同步数据的源节点复制oplog并异步的应用oplog的变更1。
1 从4.0.6版本开始，如果次要成员节点记录oplog的所花费的时间大于设定的阈值时将会在日志中打印出来。这些日志由REPL组件以
applied op: <oplog entry> took <num>ms的形式打印在诊断日志中。这些日志是否打印仅取决于设定的阈值，它不依赖于日志级别，配置级别或运行缓慢的采样率。探查器不会捕获缓慢的操作日志。
次要成员节点可以通过判断其它成员节点的ping的时间和状态来自动变更他们同步数据的源节点。
在版本3.2中的变更：有1票的复制集节点不用从0票节点上同步数据。
如果一个次要成员节点设置了members[n].buildIndexes为true，那么他只能与其它buildIndexes为true的成员节点同步。除非有其它限制条件，否则buildIndexes为false的成员节点可以从任何成员节点上同步数据。 buildIndexes默认设置为true。
多线程复写
MongoDB使用多线程来批量应用oplog数据以提高性能。MongoDB按命名空间（MMAPv1）或文档ID(WiredTiger)对批量的oplog数据进行分组，并同时使用不同的线程来应用分组后的oplog数据。MongoDB始终以原始的写入顺序来应用oplog数据到指定文档。
当应用oplog数据时，MongoDB会阻塞所有的读取操作。这样从次要成员节点上读取的查询结果将永远无法返回主要成员节点上不存在的数据。
预提取索引以提高复制吞吐量
注意：此项仅适用于MMAPv1引擎
在MMAPv1存储引擎中，MongoDB可以获取包含受影响数据和索引的内存页，以提高应用oplog数据的性能。
这个预取阶段可以最大程度的减少应用oplog数据时MongoDB保持写锁的时间。
默认配置下，次要成员节点将预取所有的索引。
可选项，您可以禁用所有预取或仅预取_id字段上的索引，详细设置可以参考secondaryIndexPrefetch参数
相关文章
- MongoDB-4.x 关于shard在启动时报错 Got signal: 6 (Aborted).
- mongodb-4.x shard cluster 搭建-复制集节点为单个节点-适合开发环境
- MongoDB-4.x 开启shard集群后批量插入性能低的问题
- mongodb生产部署手册
- mongodb：实时数据同步（一）
