1. 程式人生 > >MongoDB復制集成員及狀態轉換

MongoDB復制集成員及狀態轉換

接受 prior 故障 存在 安全性 架構 保持 用途 記錄

復制集(Replica Set)是MongoDB核心組件,相比早期版本采用的主從(Master-Slave)架構,復制集具有很多天然的優勢,包括自動故障恢復、多機房部署、讀寫行為控制等。本文介紹復制集中最基礎的部分,就是復制集成員(Replica Set Member)。大體分為成員的角色及轉換、成員狀態及轉換兩部分。

先來說說成員角色,可分為Primary、Secondary和Arbiter三類。其中前兩種是常規角色,每個復制集在正常狀態下都會有這兩種角色,Arbiter是一種特殊角色,其不包含用戶數據,僅在選舉時起作用。在這之中,Secondary又可以細分出很多熟悉,詳見下面描述。

MongoDB在分布式架構上與Raft相類似,其Leader被稱為Primary,Follower稱為Secondary,但MongoDB中沒有定義candidate角色。Primary即復制集的主節點,是唯一有權限接受客戶端寫請求的節點,會將所有的插入和更新操作記錄到oplog中,Primary也是默認所有讀請求的目標節點。Secondary復制Primary(或其他Secondary)的oplog記錄並本地回放,來保持與Primary數據一致,可設置為允許客戶端讀,但默認情況下Secondary不允許讀,需要設置slaveok參數。

技術分享圖片

Arbiter與上述兩種角色不同,其不包含用戶數據副本,復制集中添加Arbiter的目的僅僅是為了選主操作。通常在擁有偶數個節點的復制集中添加(且僅能添加)一個Arbiter,這樣可以使一次選舉中達到大多數(majority)而避免選舉分裂(split vote)。如下所示:
技術分享圖片

當Primary因為某些原因掛掉或降級時,Secondary可通過選舉成為新的Primary,原Primary恢復並重新加入復制集後,變為Secondary。Arbiter由於不包含用戶數據,所以不可能成為Primary。這是他們間的相互轉換關系。Primary、Secondary和Arbiter應獨立部署在不同的網絡節點上,對於雲環境下,也不能位於相同的宿主機上,確保相互間數據安全性和選舉獨立性。

一個復制集中僅有一個Primary,在某些特殊場景下,可能沒有Primary。Arbiter在集群中不是必須的。所以,集群中最普通的角色是Secondary,一般不少於2個。不同的Secondary可以有不同的屬性,處於不同的狀態中。Secondary屬性有如下幾類:

與選舉相關的屬性:

1、 是否能被選為Primary,該屬性由priority控制,priority越高,就越有機會成為Primary,通常情況下,Primary總是復制集中priority最高的成員,priority為0的Secondary不能被選為Primary,該特性一般用於跨機房部署時,避免failover後新Primary切到另一個機房;

技術分享圖片

2、 是否有選舉權,MongoDB復制集可以有多大50個成員,但僅允許7個成員有選舉權,該屬性由votes控制,votes為0的成員沒有選舉權,但可以否決選舉,也可以成為Primary(可以理解為無法投贊成票,都可以投反對票和發起選舉,因為被選舉權由priority控制)。MongoDB 3.0版本開始,不允許設置成員的votes大於1。
技術分享圖片

與客戶端相關的屬性:

1、客戶端是否可見,該參數由hidden控制,hidden為true表示不可見,客戶端無法從該節點讀取數據,mongos不會跟其交互;由於對客戶端不可見,則肯定不能被選舉為Primary,所以其priority屬性必須為0;該節點一般用於進行備份等用途。
技術分享圖片

與數據延遲相關的屬性:

1、slaveDelay用於控制該Secondary節點跟Primary節點的復制延遲關系,例如slaveDelay為3600,表示其數據相比Primary落後1小時,延遲判斷是通過oplog中的信息來確定。該屬性一般作為在線的歷史備份,用來回滾人為操作導致的錯誤,包括誤刪除數據庫或集合等;該屬性潛在地需要priority屬性為0,hidden屬性為true;
技術分享圖片

可以看出,相比MySQL的Replication,MongoDB的Replica Set成員的類型和屬性更為豐富,當然,主要原因是MySQL目前還是Master-Slave主從復制,所以與選舉相關的屬性或角色就沒有存在的必要。但,MySQL也有類似的slaveDelay功能。另外,尚處於實驗室狀態MySQL Group Replication正式發布將會驚動數據庫界。

聊完類型和屬性,下面再來看看成員狀態,不多不少,MongoDB一共有10種狀態,官方將其分為3大類,核心狀態(Core States)為三種成員類型對應的屬性(PRIMARY/SECONDARY/ARBITER),還有7種屬性,被分為其他狀態(Other States)和錯誤狀態(Error States)兩類。
技術分享圖片

按照時間序,其他狀態分別為STARTUP、STARTUP2和RECOVERING。每個復制集成員在mongod啟動後,都先進入STARTUP狀態,然後加載成員的復制集配置,之後進入到STARTUP2狀態。如果該成員需要進行初始同步(initial sync),那麽它將長期處於該狀態,知道同步完所有的數據和索引。隨後進入到RECOVERING狀態,處於該狀態的成員不能接受客戶端的讀請求,也不能被選舉為Primary,但可以進行投票選舉。

錯誤狀態如下所示:若成員已加入了復制集,但還未進行狀態信息同步的,會被其他復制集成員標記為UNKNOWN;若成員不再能夠通過心跳來進行狀態同步,即失去聯系,則被其他成員標記為DOWN;REMOVED表示該成員已經被移出復制集;成員處於rollback過程時,狀態為ROLLBACK,該狀態在舊的primary重新加入復制集時可能出現,用於回滾其上還未同步到其他Secondary的操作;FATAL狀態表示成員遇到了無法恢復的錯誤,必須進行人工處理。

選舉行為除了受vote和priority兩個屬性影響外,成員的狀態也會影響選舉,僅有PRIMARY, SECONDARY, RECOVERING, ARBITER和ROLLBACK五種狀態的成員允許進行投票操作。

MongoDB復制集成員及狀態轉換