MongoDB的復制集具有自動容忍部分節點宕機的功能,在復制集出現問題時時,會觸發選舉相關的過程,完成主從節點自動切換.
每個復制集成員都會在後臺運行與復制集所有節點的心跳線程,在兩種情況下會觸發狀態檢測過程:

• 復制集成員心跳檢測結果發生變化,比如某個節點掛了或者新增節點.
• 超過4s沒有執行狀態檢測過程.

在狀態檢測過程大致包含以下步驟:

• 檢測自身是否處於選舉過程,如果是,退出本次過程.
• 維護一個主節點的備用列表,列表中所有節點都可能被選舉為主節點,每個節點都會檢測自身以及全局條件是否滿足:
  • 是否看見復制集中是否有Majority在線.
  • 自身priority大於0.
  • 自身不為arbiter.
  • 自身opTime不能落後於最新節點10s以上.
  • 自身存儲的集群程序按信息為最新.

如果所有條件滿足,則將自身添加到主節點備用列表中,否則,將自身從列表中移除.

• 檢測以下條件,若都滿足,將主節點將為從節點(如果要降級的主節點是自身,直接調用降級方法,如果不為自身,調用replSetStepDown命令將復制集主節點降級為從節點.):
  • 集群中主節點存在.
  • “主節點的備用列表”中存在比當前的主節點priority更高的節點.
  • “主節點的備用列表”中priority最高的節點,其opTime要比其他所有節點最新的opTime落後10s以內.
• 檢測自身是否為主,若為主,且自身無法看見復制集的Majority在線,將自身降級為從.
• 如果看不見集群中有主節點存在,檢測自身是否在”主節點的備用列表”,若不在,打印log並退出此流程.
• 若自身在”主節點的備用列表”中,開始判斷自身可否向復制集中發送選舉自身為主節點的通知,判斷過程包含:
  • 自身是否可以看見復制集中的Majority在線.
  • 自身是否在”主節點的備用列表”.
    若條件滿足,則設置”自身已經在選舉過程中”標識位為true,並進入”選舉自身為主節點”方法.
• 方法中會驗證自身是否滿足以下條件:
  • 此線程拿到了線程鎖.
  • 此節點沒有被配置slaveDelay選項或者配置的slaveDelay為0.
  • 此節點沒有被配置為arbiter.
    若滿足,則調用環境檢測,若以下條件被觸發,則不發送“選舉我為主節點”投票:
  • 當前時間小於steppedDown的結束凍結時間(為執行steppedDown時的時間+凍結設定時間,內部調用為60s).
  • 自己的opTime不是所有節點最新的.
    • 若有節點opTime比自己新,直接退出此流程.
    • 如果其他最新的節點最多與自己一樣新,每有一個這樣的節點,隨機sleep一段時間,之後繼續判斷.
  • 自己上線5分鐘內且復制集中不是所有節點在線.
• 如無其他問題,嘗試獲取自己進行投票時的票數,在此過程中,會判斷自己在30s內是否進行過投票,如進行過,直接退出整個過程.
• 經過以上種種復雜的檢測,終於可以向復制集發送”選舉我為主節點”的投票.
• 發送之後,會接收來自所有節點的投票,若得票數小於等於一半,不將自己變為主節點,若超過一半,設置自己為主節點.
  投票結束後,設置”自身已經在選舉過程中”標識位為false.
  可以看到,上面的判斷邏輯有一些是重復判斷,不過不影響最終結果,可能與判斷邏輯較為復雜有關系,在每個決定之前都要驗證所有條件是否滿足,防止有條件被漏掉.
  在復制集中的節點收到其他節點發送的”選舉我為主節點”投票信息時,會有以下的判斷:
• 若自身存儲的復制集配置版本過低,不投票.
• 若發起請求的節點存儲的復制集配置版本過低,投反對票.
• 如果自身所在的復制集沒有發起投票的節點,投反對票.
• 復制集中存在主節點,投反對票.
• 可參與選舉的節點中有priority高於請求為主的節點存在時,投反對票.
  如果所有條件通過,獲取自身的投票數(同樣會判斷自身在30s內是否參加過投票,若參加過,不再投票),投出票數.
  需要說一下的是,一個反對會將最終票數減10000,即在絕大多數情況下,只要有節點反對,請求的節點就不能成為主節點.
  選舉過程很復雜,實際使用中總結為兩點:
• 一般情況下需要5s左右進行選主.
• 如果新選舉出的主節點立馬掛掉,至少需要30s時間重新選主.

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　轉自MongoDB中文社區

MongoDB選舉過程