標籤：http io ar 使用 sp on 問題 log bs
轉自：http://www.mongoing.com/archives/295
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的選舉過程（轉）
