MongoDB的選舉過程是怎樣的

本篇文章給大家分享的是有關MongoDB的選舉過程是怎樣的，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

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時間重新選主.

以上就是MongoDB的選舉過程是怎樣的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。