MongoDB複製集成員及狀態轉換
複製集(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五種狀態的成員允許進行投票操作。
推薦閱讀:
※TiKV 源碼解析系列 - Lease Read
※如何系統學習 MySQL?
※終於等到你——MySQL 5.7與PostgreSQL 9.6的百萬QPS大比拼
※如何理解資料庫的內部一致性和外部一致性?