标签：安全 prim 操作 version 集群 节点 版本 protoc 怎么
因为一些特殊原因，重新复习了一下MongoDB的选举机制.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在与集群内大多数节点心跳超时的时候，会选择自我降级，保护集群
priority大于0的节点，votes必须大于0。priority影响了节点成为primary的可能性，同一个集群中，始终会选择priority值为最大的那个节点成为primary。如果某些情况下，非最大priority的节点成为了primary，集群也会重新发起选举，直到priority最大的节点被选举成为primary。如果节点的priority相同，则会优先根据本地oplog的操作时序，使拥有最新操作记录的secondary被选举成为primary。
标签：安全 prim 操作 version 集群 节点 版本 protoc 怎么
原文地址：https://blog.51cto.com/387249/2513357
