複習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。