复习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。