replicaSet的初始化和同步原理

ReplicaSet的初始化initial

除了local数据库，mongod扫描所有数据库的所有集合，并插入到secondary

在3.4之前，初始化只会建立所有集合中_id上的索引到从节点，3.4以后会建立所有的索引

在3.4以后，初始化会拉最新的oplog到从节点，在初始化结束前需要确保从节点local库的空间

当初始化完成并开始应用oplog时，这个mongod就变成了secondary

replicaSet的同步sync

secondary成员在初始化完成后立即开启复制oplog，并应用oplog上的变更操作

流复制

mongo4.4开始，sync支持流复制oplog

心跳

每个成员每隔2s会向其他成为发送心跳请求，心跳请求信息量非常小，用于检查每个成员的状态

成员状态

startup 成员刚启动时的状态，加载完复制集配置后，进入startup2状态

startup2 整个初始化initial过程处于startup2状态

recovering 成员正在sync，此时不能处理读请求

arbiter 仲裁节点的正常状态

down 成员不可达

unknown 其他成员不知道该成员的状态

remove 成员被移除副本集

rollback 成员正在进行回滚

fatal 成员发生不可挽回的错误，不再尝试恢复正常。通常需要查询日志分析原因，可能需要重新sync或从备份中恢复

initial选举和sync选举

initial选举和sync选举，都是为了选举出可用的源，因为同步数据源可用不是主节点，可用是其他从节点。具体规则查看官方文档的selection部分

initialSyncSourceReadPreference参数

primary：设置sync源为primary，如果primary不可用便重试并输出log

primaryPrefered：设置sync源为primary，如果primary不可用便尝试使用其他可用从节点

settings.chainingAllowed

当settings.chainingAllowed为true时，允许复制集中的从节点连接到其他从节点进行复制，当false时，从节点只能连接主节点

回滚

如果一个主节点A在执行了写请求x1，所有备节点Bn还没有进行这个操作时，主节点挂了。这些备节点通过选举新的主节点B1提供服务，这个时候之前挂掉的主节点A和新主节点B1的数据是不一致的，而且漏掉的写请求x1因为业务逻辑关系无法直接复制到B1。如果这A这时连接回复制集，A必须进行回滚x1。

如果回滚量过大，mongoDB可能会回滚失败。这种情况就是被节点远远落后于主节点

总结：mongoDB4.4刚刚实现流复制，还没有半同步或者保护模式的形式来保护数据的强可靠性。

参考文档：

《mongoDB权威指南》