MongoDB - 副本集簡介

簡介

在 MongoDB 中，副本集指的是一組 MongoDB 服務器實體掌管同一個資料集，實體可以在不同的機器上，

其中一個用于處理寫操作的是主節點（Primary），還有多個用于保存主節點的資料副本的從節點（Secondary），如果主節點崩潰了，則從節點會從其中選取出一個新的主節點，

副本集保證資料在生產部署時的冗余和可靠性，通過在不同的機器上保存副本來保證資料不會因為單點損壞而丟失，能夠隨時應對資料丟失、機器損壞帶來的風險，

從另一個角度上看，還能提高讀取能力，用戶的讀取服務器和寫入服務器在不同的地方，由不同的服務器為不同的用戶提供服務，提高了整個系統的負載能力，

節點成員

副本集中的節點主要分為三種：主節點 Primary、從節點 Seconary、仲裁節點 Arbiter，

主節點

主節點包含了所有的寫操作的日志，

但是副本服務器集群包含有所有的主服務資料，因此當主服務器掛掉了，就會在副本服務器上重新選取一個成為主服務器，

從節點

正常情況下，副本集的從節點會參與主節點選舉，并從主節點同步最新寫入的資料，以保證與主節點存盤相同的資料，

通常，從節點提供讀服務，增加從節點可以提供副本集的讀服務能力，同時提升副本集的可用性，

仲裁節點

仲裁節點只參與投票，不能被選舉為主節點，并且不從主節點同步資料，

當副本集成員為偶數時，最好加入一個仲裁節點，以提升副本集的可用性，

當然，如果可以的話，最好使用沒有仲裁者的部署，添加額外的仲裁者并不能加快選舉速度，也不能提供更好的資料安全性，僅僅能使得副本集成員數為奇數防止選舉出現平票，

被動成員

給從節點設定 priority 可以指定其成為主節點的優先級，它的取值范圍是 0 到 100，默認是 1，

優先級為 0 的從節點不參與選舉，這樣的從節點被稱為被動成員，

擁有最高優先級的成員總是會被選舉為主節點（只要它能連接到副本集中的大多數成員，并且擁有最新的資料），

隱藏成員

給從節點設定 hidden 為 true 可以將其作為隱藏成員，隱藏成員只對 isMaster 不可見，

客戶端不會向隱藏成員發送請求，隱藏成員也不會優先作為副本集的資料源（盡管當其他復制源不可用時隱藏成員也會被使用），

通常會將性能較弱的服務器或者備份服務器隱藏起來，因此，隱藏成員適合做資料備份、離線計算的任務，

成員狀態

成員之間通過心跳來傳達自己的狀態，最常見的狀態就是“主節點”和“從節點”狀態，其他的一些狀態如下：

• STARTUP: 成員在第一次啟動時的狀態，正在嘗試加載副本集配置
• STARTUP2: 配置被加載后進入這個狀態，初始化同步程序會持續處于這個狀態
• RECOVERING: 成員運行正常，但不能處理讀請求
• ARBITER: 仲裁節點獨有的特殊狀態
• DOWN: 一個成員被正常啟動，但后來變為不可訪問
• UNKNOWN: 如果一個成員未能訪問到另一個成員，那么就不知道它處于什么狀態
• REMOVED: 此成員已被從副本集中移除
• ROLLBACK: 成員正在回滾資料中會處于此狀態

部署架構

一主兩從

當主節點宕機時，兩個節點都會參與選舉，其中一個會變成主節點，

當原主節點恢復后，將會作為從節點加入當前的副本集群，

一主一從一仲裁

當主節點宕機時，將會選擇從節點稱為主節點，

當原主節點恢復后，將會作為從節點加入當前的副本集群，

推薦配置

第一種方案是：將“大多數”成員放在一個資料中心，只要主資料中心正常運轉，就會有一個主節點，如果主資料中心不可用了，那么備份資料中心將無法選舉出主節點，

第二種方案是：在兩個資料中心各自放置數量相等的成員，在第三個地方放置一個用于打破僵局的副本集成員，

復雜的需求可能需要不同的配置，但都需要考慮副本集在不利條件下如何滿足“大多數”的要求，

資料同步

操作日志

MongoDB 的操作日志是一個特殊的有上限的集合（老的日志會被覆寫），保存了所有資料庫中存盤資料的修改操作的滾動記錄，

當主節點執行資料庫寫操作時，會將這些操作記錄到主節點 local 資料庫中的一個固定集合中，然后從節點通過異步行程復制和應用（資料同步）這些操作，

每個從節點都維護自己的操作日志，用于記錄從主節點復制的每個操作，這使得每個成員都可以被用作其他成員的同步源，

操作日志中的每個操作都是冪等的，同一個操作執行多次和只執行一次效果是一樣的，

在大多數情況下，默認的操作日志大小就足夠了，通常以下情況需要更大的操作日志空間：

• 一次更新多個檔案，操作日志為了保持冪等性會將多檔案更新轉換成多個單獨操作
• 洗掉資料量與插入資料量相同，這種情況的磁盤占用變化不大，但是操作日志的大小可能很大
• 大量的原地（in-place）更新，這種情況的磁盤占用變化不大，但是操作日志的大小可能很大

初始同步

這里的初始同步可以理解成全量同步，會使用完整的資料集填充新成員，會有以下場景觸發：

• 新節點加入副本集時，沒有任何操作日志，此時會觸發初始同步
• 上次全量同步中途失敗后重新加入副本集，此時會觸發初始同步
• 當用戶發送 resync 命令時，記憶體標記 initialSyncRequested 被設定為 true，此時會觸發初始同步

全量同步的流程如下：

• 全量同步開始，設定 minvalid 集合的 _initialSyncFlag 為 true
• 獲取同步源上最新操作日志時間戳為 t1
• 全量同步集合資料（耗時）
• 獲取同步源上最新操作日志時間戳為 t2
• 重放 [t1, t2] 范圍內的所有操作日志
• 獲取同步源上最新操作日志時間戳為 t3
• 重放 [t2, t3] 范圍內所有的操作日志
• 建立集合所有索引（耗時）
• 獲取同步源上最新操作日志時間戳為 t4
• 重放 [t3, t4] 范圍內所有的操作日志
• 全量同步結束，清除 minvalid 集合的 _initialSyncFlag

復制資料

這里的復制可以理解為增量同步，在初始同步結束之后，從節點就會持續同步新的操作日志并重放，

復制的流程比較復雜，會涉及到幾個執行緒，其流程如下：

• 生產者執行緒會不斷從同步源上拉取操作日志，并加入到一個阻塞佇列里保存
• 批處理執行緒會逐步將阻塞佇列里的操作日志取出，并放到自己維護的佇列里
• 同步執行緒將批處理執行緒的佇列分發到默認 16 個重放執行緒，由重放執行緒最終重放每條操作日志

拉取操作日志是單執行緒進行的，如果把重放的操作也放在這個執行緒，同步勢必會很慢，所以設計上生產者執行緒只做拉取操作日志的作業，

在重放操作日志時，要保持順序性，而且遇到 createCollection()、dropCollection() 等 DDL 命令時，這些命令與其他的增刪查改是不能并行執行的，這些控制都有批處理執行緒處理，

注意事項

• 初始同步是單執行緒復制資料，效率比較低，在生產上應盡量避免做全量同步
• 合理配置操作日志的大小，按默認 5% 的可用磁盤空間配置可滿足絕大多數場景
• 新加入節點時，可以通過物理復制的方式來避免初始同步，將主節點的資料拷貝到新的節點，這樣效率更高
• 當從節點需要的操作日志在同步源上已經滾掉，從節點的同步將無法進行，需要從節點主動發送 rsync 命令同步
• 生產環境使用 db.printSlaveReplicationInfo() 命令監控主備同步滯后的情況
• 當從節點因為主節點并發寫入太高導致同步滯后，可通過調整從節點的重放執行緒數來提升

資料高可用

選舉機制

在副本集中，通過選舉機制來選擇主節點，選舉主節點的規則如下：

假設副本集內能夠投票的成員是 N 個，當副本集記憶體活數量不足 \(\frac{N}{2} + 1\) 個時，整個副本集將無法選舉出主節點，副本集將無法提供寫服務，處于只讀狀態，

舉例：3 個投票節點需要 2 個節點的贊成票，容忍選舉失敗次數為 1；5 個投票節點需要 3 個節點的贊成票，容忍選舉失敗次數為 2；通常投票節點為奇數，這樣可以減少選舉失敗的概率，

觸發時機

當出現以下情況時，會觸發選舉機制：

• 初始化副本集時
• 往副本集中新加入節點
• 對副本集進行維護時，比如執行 rs.stepDown() 或者 rs.reconfig() 操作時
• 從節點失聯時，比如超時（默認是 10 秒）

影響因素

以下因素會影響到選舉結果：

• 副本集的選舉協議
• 心跳
• 成員權重
• 資料中心失聯
• 網路磁區
• 鏡像讀取

故障轉移回滾

回滾指的是，當成員在故障轉移后重新加入其副本集時，將還原之前主節點上的寫操作，并恢復成現在主節點的狀態資料，

僅當節點接收到主節點降級前未成功復制的寫操作后，重新加入副本集群之后發現與現有主節點的資料不一致時，才需要回滾，

當節點重新加入到副本集群時，它會還原或“回滾”其不一致的寫操作，以保持與其他成員的一致性，

與副本集互動

客戶端連接

對于副本集，默認情況下，驅動程式會連接到主節點，并將所有流量都路由到此節點，

對于應用程式，可以像與單機服務器通信一樣執行讀寫操作，同時副本集會在后臺悄悄地處理熱備份，

你不需要列出服務器地址串列中的所有成員（盡管這樣做也可以），當驅動程式連接到服務器時，它可以從其中發現其他成員，一個連接字串通常看起來像下面這樣：

mongodb://server-1:27017,server-2:27017,server-3:27017

如果想提供更強的容錯能力，那么也可以使用 DNS 種子串列連接格式來指定應用程式連接到副本集的方式，

使用 DNS 的優點是可以輪流更改 MongoDB 副本集成員所在的服務器，而無須重新配置客戶端，

重試策略

用戶希望驅動程式對其隱藏整個選舉程序（主節點退位，新的主節點被選舉出來），然而，由于一些原因，沒有驅動程式能夠以這種方式處理故障轉移，

驅動程式經常因為操作失敗而發現主節點已停止運行，這意味著驅動程式不知道主節點在停止運行之前是否處理了該操作，

這是一個不可避免的分布式系統問題，事實證明，正確的策略是最多重試一次，

要解釋清楚這一點，需要先看一下都有哪些策略可供選擇，歸結起來就是：不重試、在重試一定次數后放棄或者最多只重試一次，

我們還需要考慮錯誤的型別，這可能是問題的根源，在嘗試對副本集進行寫操作的程序中，可能

會遇到 3 種型別的錯誤：

• 短暫的網路錯誤
• 持續的中斷（網路或服務器）
• 由服務器拒絕的錯誤命令（比如未授權）引起的錯誤

對于短暫的網路錯誤而言，如果遵循重試一定次數的策略，則可能會發生計數過多現象（在第一次嘗試成功的情況下），對于持續中斷或命令錯誤，多次重試只會浪費資源，

再來看一下僅重試一次的策略，對于短暫的網路錯誤，可能會發生計數過多現象，對于持續的中斷或命令錯誤，這是正確的策略，

然而，如果可以確保操作是冪等的會如何？無論做一次還是多次，冪等操作都會有相同的結果，利用冪等操作，在發生網路錯誤時重試一次最有可能正確處理所有 3 種型別的錯誤，

讀寫優先級

默認情況下，副本集的所有讀請求都發送到主節點，Driver 可通過設定 Read Preference 來將請求路由到其他節點，規則如下：

• primary: 默認規則，所有讀請求發送到主節點
• primaryPreferred: 主節點優先，如果主節點不可達，請求從節點
• secondary: 所有讀請求發送到從節點
• secondaryPreferred: 從節點優先，當所有從節點不可達時請求主節點
• nearest: 讀請求發送到最近的可達節點上（通過 ping 探測得出最近的節點）

讀請求選擇

其實，將讀請求發送到從節點通常并不是一個好主意，在一些情況下，通常更建議將讀請求發送到主節點而不是從節點，

對于資料一致性要求非常高的應用程式，更推薦從主節點讀取資料，這是由于從節點的資料通常會落后于主節點，并且這個時間有可能因其他原因導致更長，

如果將讀請求發送到從節點以分配負載，有可能會因為一個節點崩潰而導致整個副本集出現過載的情況，這個會導致惡性回圈，一個更好的選擇是使用分片來分配負載，

注意事項

在生產環境中，應該始終使用副本集并為每個成員分配一個專用主機，以避免資源爭用，并針對服務器故障提供隔離，

為了提供更多的彈性，還應該使用 DNS 種子串列連接格式指定應用程式如何連接到副本集，其優點在于可以輪流更改托管 MongoDB 副本集成員的服務器，而無須重新配置客戶端，

副本集中的每個成員都必須能夠連接到其他成員（包括自身），但是 MongoDB 3.6 中 mongod 僅在默認情況下系結到 localhost（127.0.0.1） 地址上，這個通常需要根據服務本身的地址做配置修改，

并且，在系結到非 localhost 的地址之前，應該啟用授權控制并指定身份驗證機制，

另外，最好對磁盤上的資料和副本集成員之間以及副本集與客戶端之間的通信進行加密，

需要注意的是，不能在不停止運行的情況下將單機服務器轉換為副本集，以重新啟動并初始化該副本集，

因此，即便一開始只有一臺服務器，你也希望將其設定為一個單成員的副本集，這樣，就可以在不停止運行的情況下進行添加，

常見問題

MongoDB 副本集和 MySQL 主從的區別？

從節點讀寫模式

MySQL 中將主從同步的從庫設定為只讀狀態，限制了普通用戶只能進行讀的操作，但限制不了超級權限用戶對資料進行修改操作，這種情況容易造成主鍵沖突，

MongoDB 中只有主節點才可進行寫操作，從節點是決不允許寫資料的，對資料的一致性有著更高的保證，

主節點唯一性

MongoDB 中主節點是唯一的，其余均為從節點，但主節點不是固定不變的，集群內部有容災機制，

MySQL 提供了雙主架構方案，MasterA 和 MasterB，MasterA 可以做為 MasterB 的主庫，而 MasterB 也可以做為 MasterA 的主庫，兩者互為主從，

復制程序中是同步還是異步

MySQL 在 5.5 版本之后提供了半同步復制模式，是介于異步復制和同步復制之間，主庫在執行完客戶端提交的事務后不是立刻回傳給客戶端，而是等待至少一個從庫接收到并寫到 relay log 中才回傳給客戶端，相對于異步復制，半同步復制提高了資料的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個 TCP/IP 往返的時間，所以，半同步復制最好在低延時的網路中使用，

MongoDB 的同步模式是完全異步的，

MongoDB 副本集的最大節點數為多少？

在副本集中，每個節點會向其他節點發送心跳請求，間隔時間為 2 秒，默認 10 秒為超時，從這個角度上看，副本集也相當于無中心架構，

當副本集中節點增加時，心跳請求的數量將會以指數級的數量增加，單單是心跳請求對資源的占用也會很大，

因此，在 MongoDB 中副本集的限制為最大 50 個，同時只有 7 個成員擁有投票權，

MongoDB 主節點宕機之后如何進行選舉？

副本集中的健康節點大于集群節點的 \(\frac{1}{2}\) 時，集群才可正常選舉，否則集群將不可寫，只能讀，

這個限制會存在一個情況：副本集原本有 3 個節點，但是其中 2 個從節點因為例外掛掉了，那么集群檢測之后主節點也將會降級為從節點，只接受讀，不再接受寫入，

官方推薦在副本集中有投票權的節點數量為奇數個，主要是為了避免出現腦裂（一個集群被分成了多個集群）的情況，

首發于「程式員翔仔」，點擊查看更多，

標籤：其他

上一篇：圖文結合帶你搞懂MySQL日志之Slow Query Log（慢查詢日志）

下一篇：數字化時代，校園生活還可以這樣過