复习MongoDB选举机制

因为一些特殊原因,重新复习了一下MongoDB的选举机制.

replica set protocol

Mongo 3.2之后上线了Replicaset protocol version1,用以取代之前的version0(3.6之后的版本默认是version1),增加了dry-run模式,也就是选举节点会在发起真正的选举前尝试询问其他节点,自己是否可以成为primary,在得到肯定答复后才会发起真正选举。这个举措避免了由于发生network partition之后某个节点不断发起选举而造成的term爆炸增长,减少不必要的failover。

怎么避免脑裂?

脑裂发生于network partition的情况下,也就是节点未宕机,但是网络断联。
避免脑裂最直接的方法就是确保replica set有奇数个voting members。这个对于跨网络环境部署(通常是跨机房,云环境可能是跨region)replica set很重要,确保奇数个节点,会让某个环境内包含大多数voting member的剩余节点仍然可以选举出primary。另一侧的剩余节点,则会因为看不见集群的大多数节点,然后出于安全,降级为seconday。

什么是大多数节点?

大多数节点是指大于一半的节点数量,比如3就是2,4就是3,5就是3,6就是4,7就是4。

选举的限制

replica set在最新版中,最大可以拥有50个members,7个voting members。

primary的降级

primary在与集群内大多数节点心跳超时的时候,会选择自我降级,保护集群

priority的作用

priority大于0的节点,votes必须大于0。priority影响了节点成为primary的可能性,同一个集群中,始终会选择priority值为最大的那个节点成为primary。如果某些情况下,非最大priority的节点成为了primary,集群也会重新发起选举,直到priority最大的节点被选举成为primary。如果节点的priority相同,则会优先根据本地oplog的操作时序,使拥有最新操作记录的secondary被选举成为primary。

复习MongoDB选举机制

上一篇:javaweb 解决实体中属性和数据库中列名不一致问题


下一篇:Postgresql中的位图扫描(bitmap scan)