MongoDB副本集心跳和同步机制

MongoDB建议副本集成员为奇数。最多12个副本节点，最多7个节点参与选举。
限制副本节点的数量，主要是因为一个集群中过多的副本节点，增加了复制的成本，反而拖累了集群的整体性能。
太多的副本节点参与选举,也会增加选举的时间。而官方建议奇数的节点，是为了避免脑裂的发生。

考虑如下场景，一个MongoDB集群有4个节点。分布在两个网段。

如果两个网段的网络发生故障，则每个网段都有两个节点存活，他们查看自己的映射表,不能确定对方是否已死，也不能确定自己是否能成为主节点。
如果他们各自推选出主节点，则集群网络恢复的时候，就会有两个主节点，数据无法达成一致。所以这个时候，MongoDB会选择让所有的节点只读。

两个节点也是同样的问题，一旦出现故障，每个节点都不能判断是自己出了问题，还是对方出了问题。所以他们都会选择将自己设置为只读。

整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每两秒就会发送一次pings包，如果其他节点在10秒钟之内没有返回就标示为不能访问。每个节点内部都会维护一个状态映射表，表明当前每个节点是什么角色、日志时间戳等关键信息。如果是主节点，除了维护映射表外还需要检查自己能否和集群中内大部分节点通讯，如果不能则把自己降级为secondary只读节点。

 

副本集同步分为初始化同步和keep复制。初始化同步指全量从主节点同步数据，如果主节点数据量比较大同步时间会比较长。而keep复制指初始化同步过后，节点之间的实时同步一般是增量同步。初始化同步不只是在第一次才会被触发，有以下两种情况会触发：

secondary第一次加入，这个是肯定的。

secondary落后的数据量超过了oplog的大小，这样也会被全量复制。

 

那什么是oplog的大小？前面说过oplog保存了数据的操作记录，secondary复制oplog并把里面的操作在secondary执行一遍。但是oplog也是mongodb的一个集合，保存在local.oplog.rs里，但是这个oplog是一个capped collection也就是固定大小的集合，新数据加入超过集合的大小会覆盖。所以这里需要注意，跨IDC的复制要设置合适的oplogSize，避免在生产环境经常产生全量复制。oplogSize 可以通过–oplogSize设置大小，对于linux 和windows 64位，oplog size默认为剩余磁盘空间的5%。

 

同步也并非只能从主节点同步，假设集群中3个节点，节点1是主节点在IDC1，节点2、节点3在IDC2，初始化节点2、节点3会从节点1同步数据。后面节点2、节点3会使用就近原则从当前IDC的副本集中进行复制，只要有一个节点从IDC1的节点1复制数据。

 

设置同步还要注意以下几点：

secondary不会从delayed和hidden成员上复制数据。

只要是需要同步，两个成员的buildindexes必须要相同无论是否是true和false。buildindexes主要用来设置是否这个节点的数据用于查询，默认为true。

如果同步操作30秒都没有反应，则会重新选择一个节点进行同步。