摘要：大體分為成員的角色及轉換成員狀態及轉換兩部分。每個復制集成員在啟動后，都先進入狀態，然后加載成員的復制集配置，之后進入到狀態。選舉行為除了受和兩個屬性影響外，成員的狀態也會影響選舉，僅有和五種狀態的成員允許進行投票操作。

此文已由作者溫正湖授權網易云社區發布。

歡迎訪問網易云社區，了解更多網易技術產品運營經驗。

復制集（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五種狀態的成員允許進行投票操作。

網易云免費體驗館，0成本體驗20+款云產品！

更多網易技術、產品、運營經驗分享請點擊。

文章來源： 網易云社區