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屬性有以下幾類：

 

與選舉相關的屬性：

 

一、  是否能被選爲Primary，該屬性由priority控制，priority越高，就越有機會成爲Primary，一般狀況下，Primary老是複製集中priority最高的成員，priority爲0的Secondary不能被選爲Primary，該特性通常用於跨機房部署時，避免failover後新Primary切到另外一個機房；

 

 

二、  是否有選舉權，MongoDB複製集能夠有多大50個成員，但僅容許7個成員有選舉權，該屬性由votes控制，votes爲0的成員沒有選舉權，但能夠否決選舉，也能夠成爲Primary（能夠理解爲沒法投同意票，均可以投反對票和發起選舉，由於被選舉權由priority控制）。MongoDB 3.0版本開始，不容許設置成員的votes大於1。

 

 

與客戶端相關的屬性：

 

  一、客戶端是否可見，該參數由hidden控制，hidden爲true表示不可見，客戶端沒法從該節點讀取數據，mongos不會跟其交互；因爲對客戶端不可見，則確定不能被選舉爲Primary，因此其priority屬性必須爲0；該節點通常用於進行備份等用途。

 

 

與數據延遲相關的屬性：

 

  一、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+款雲產品！ 

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

 

相關文章：
【推薦】 關於評審--從思想到落地