不过开始今天的正文前，需要介绍一下mongodb在slave结点上进行数据同步时的一个大致流程：
1. 当一个从结点启动时，它会对主结点进行一次彻底同步。从结点将复制主结点中的每一个文档（操作量大且耗时）。当初始化的同步完成后，从结点将查询主结点的oplog并且执行这些操作来保持数据的更新。
2. 如从结点上的操作落后主结点太多， 从结点处于out-of-sync状态。该状态表示从结点不能通过执行同步操作使本地数据赶上主结点数据，因为主结点中的每一个操作都太新了。造成这种情 况的原因包括结点宕机或者忙于处理读请求（尽管mongodb支持读操作的负载均衡）。如果同步的时间(戳)超出了oplog(滚动)的时间(戳)，它将 重新开始一次彻底的同步（通过执行resync操作）。
3. 当一个从结点处于out-of- sync状态时，复制将被挂起，从结点需要从主结点进行重新同步。resync流程可以手动执行，即在从结点的admin数据库上运行命令 {“resync”：1}， 或者自动执行：在启动从结点时使用 --autoresync选项。因为resync是非常操作量大且耗时，最好通过设置一个足够大的oplogSize来避免resync（默认的 oplog大小是空闲磁盘大小的5%）。
为了验证上面的流程，下面我们就来看一下slave的执行流程。这里为了便于调试，对环境配置如下：
1.master db ip-> 10.0.4.210
启动命令行：d:\mongod>bin>mongod --dbpath=d:\mongodb\db --master --oplogSize 64
2.在vs中做如下设置（mongod项目属性窗口）：
--slave --source 10.0.4.210:27017 --only test --slavedelay 100
因为mongod的主入口函数在db.cpp中，我们可以通过下面方法的调用流程找到slave的蛛丝马迹：
最新评论