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