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秒都没有反应,则会重新选择一个节点进行同步。


登录后回复
 

与 萌阔论坛 的连接断开,我们正在尝试重连,请耐心等待