MongoDB的選舉過程

chenfeng發表於2018-12-27

MongoDB的複製集具有自動容忍部分節點當機的功能,在複製集出現問題時時,會觸發選舉相關的過程,完成主從節點自動切換.

每個複製整合員都會在後臺執行與複製集所有節點的心跳執行緒,在兩種情況下會觸發狀態檢測過程:

1).複製整合員心跳檢測結果發生變化,比如某個節點掛了或者新增節點.

2).超過4s沒有執行狀態檢測過程.


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

1).檢測自身是否處於選舉過程,如果是,退出本次過程.

2).維護一個主節點的備用列表,列表中所有節點都可能被選舉為主節點,每個節點都會檢測自身以及全域性條件是否滿足:

a.是否看見覆制集中是否有Majority線上.

b.自身priority大於0.

c.自身不為arbiter.

d.自身opTime不能落後於最新節點10s以上.

e.自身儲存的叢集程式按資訊為最新.


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

1).檢測以下條件,若都滿足,將主節點將為從節點(如果要降級的主節點是自身,直接呼叫降級方法,如果不為自身,呼叫replSetStepDown命令將複製集主節點降級為從節點.):

a.叢集中主節點存在.

b.“主節點的備用列表”中存在比當前的主節點priority更高的節點.

c.“主節點的備用列表”中priority最高的節點,其opTime要比其他所有節點最新的opTime落後10s以內.

2).檢測自身是否為主,若為主,且自身無法看見覆制集的Majority線上,將自身降級為從.

3).如果看不見叢集中有主節點存在,檢測自身是否在”主節點的備用列表”,若不在,列印log並退出此流程.

4).若自身在”主節點的備用列表”中,開始判斷自身可否向複製集中傳送選舉自身為主節點的通知,判斷過程包含:

a.自身是否可以看見覆制集中的Majority線上.

b.自身是否在”主節點的備用列表”.

c.若條件滿足,則設定”自身已經在選舉過程中”標識位為true,並進入”選舉自身為主節點”方法.

5).方法中會驗證自身是否滿足以下條件:

a.此執行緒拿到了執行緒鎖.

b.此節點沒有被配置slaveDelay選項或者配置的slaveDelay為0.

c.此節點沒有被配置為arbiter.

若滿足,則呼叫環境檢測,若以下條件被觸發,則不傳送“選舉我為主節點”投票:

d.當前時間小於steppedDown的結束凍結時間(為執行steppedDown時的時間+凍結設定時間,內部呼叫為60s).

e.自己的opTime不是所有節點最新的.

若有節點opTime比自己新,直接退出此流程.

如果其他最新的節點最多與自己一樣新,每有一個這樣的節點,隨機sleep一段時間,之後繼續判斷.

f.自己上線5分鐘內且複製集中不是所有節點線上.

6).如無其他問題,嘗試獲取自己進行投票時的票數,在此過程中,會判斷自己在30s內是否進行過投票,如進行過,直接退出整個過程.

7).經過以上種種複雜的檢測,終於可以向複製集傳送”選舉我為主節點”的投票.

8).傳送之後,會接收來自所有節點的投票,若得票數小於等於一半,不將自己變為主節點,若超過一半,設定自己為主節點.

投票結束後,設定”自身已經在選舉過程中”標識位為false.

可以看到,上面的判斷邏輯有一些是重複判斷,不過不影響最終結果,可能與判斷邏輯較為複雜有關係,在每個決定之前都要驗證所有條件是否滿足,防止有條件被漏掉.

在複製集中的節點收到其他節點傳送的”選舉我為主節點”投票資訊時,會有以下的判斷:

9).若自身儲存的複製集配置版本過低,不投票.

10).若發起請求的節點儲存的複製集配置版本過低,投反對票.

11).如果自身所在的複製集沒有發起投票的節點,投反對票.

12).複製集中存在主節點,投反對票.

13).可參與選舉的節點中有priority高於請求為主的節點存在時,投反對票.

如果所有條件透過,獲取自身的投票數(同樣會判斷自身在30s內是否參加過投票,若參加過,不再投票),投出票數.

需要說一下的是,一個反對會將最終票數減10000,即在絕大多數情況下,只要有節點反對,請求的節點就不能成為主節點.

選舉過程很複雜,實際使用中總結為兩點:

a.一般情況下需要5s左右進行選主.

b.如果新選舉出的主節點立馬掛掉,至少需要30s時間重新選主.


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/15498/viewspace-2286612/,如需轉載,請註明出處,否則將追究法律責任。

相關文章