mongodb的複製集具有自動容忍部分節點宕機的功能,在複製集出現問題時時,會觸發選舉相關的過程,完成主從節點自動切換.
每個複製集成員都會在後台執行與複製集所有節點的心跳執行緒,在兩種情況下會觸發狀態檢測過程:
在狀態檢測過程大致包含以下步驟:
如果所有條件滿足,則將自身新增到主節點備用列表中,否則,將自身從列表中移除.
如果看不見集群中有主節點存在,檢測自身是否在」主節點的備用列表」,若不在,列印log並退出此流程.
若自身在」主節點的備用列表」中,開始判斷自身可否向複製集中傳送選舉自身為主節點的通知,判斷過程包含:
自身是否在」主節點的備用列表」.
若條件滿足,則設定」自身已經在選舉過程中」標識位為true,並進入」選舉自身為主節點」方法.
方法中會驗證自身是否滿足以下條件:
如無其他問題,嘗試獲取自己進行投票時的票數,在此過程中,會判斷自己在30s內是否進行過投票,如進行過,直接退出整個過程.
經過以上種種複雜的檢測,終於可以向複製集傳送」選舉我為主節點」的投票.
傳送之後,會接收來自所有節點的投票,若得票數小於等於一半,不將自己變為主節點,若超過一半,設定自己為主節點.
投票結束後,設定」自身已經在選舉過程中」標識位為false.
可以看到,上面的判斷邏輯有一些是重複判斷,不過不影響最終結果,可能與判斷邏輯較為複雜有關係,在每個決定之前都要驗證所有條件是否滿足,防止有條件被漏掉.
在複製集中的節點收到其他節點傳送的」選舉我為主節點」投票資訊時,會有以下的判斷:
若自身儲存的複製集配置版本過低,不投票.
若發起請求的節點儲存的複製集配置版本過低,投反對票.
如果自身所在的複製集沒有發起投票的節點,投反對票.
複製集中存在主節點,投反對票.
可參與選舉的節點中有priority高於請求為主的節點存在時,投反對票.
如果所有條件通過,獲取自身的投票數(同樣會判斷自身在30s內是否參加過投票,若參加過,不再投票),投出票數.
需要說一下的是,乙個反對會將最終票數減10000,即在絕大多數情況下,只要有節點反對,請求的節點就不能成為主節點.
選舉過程很複雜,實際使用中總結為兩點:
一般情況下需要5s左右進行選主.
如果新選舉出的主節點立馬掛掉,至少需要30s時間重新選主.
zk選舉過程
zk集群的執行模式 1.名詞解釋 client 使用zk集群服務的客戶端 leader zk集群真正對外服務的機器，乙個zk集群只有一台leader伺服器 flower zk集群中除leader伺服器的其他伺服器 zk集群中每個機器都是通過tcp實現連線，通過心跳的機制檢測服務是否正常 2.lead...
zookeeper的選舉過程
ookeeper的選舉過程大致如下 選出乙個在n 2 1個節點中選出乙個節點為主節點 比如三個組成的集群 n 2 1 2 第二台是master 比如三個組成的集群 n 2 1 3 第三台是master zookeeper的選舉過程，就是選出乙個在n 2 1個節點中選出乙個節點為主節點的過程。比如，當...
zookeeper Leader的選舉過程
假如有三個節點 s1,s2,s3 組成的集群。在集群啟動過程中，當有一台zookeeper節點s1啟動完成後，此時集群中只有乙個節點無法進行leader的選舉。當第二個節點s2啟動成功後，此時兩個節點可以正常通訊，進入leader的選舉過程，具體如下 每乙個節點都是自私的，各自都投自己1票。每次投票...