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 個從節點因為異常掛掉了，那麼集群檢測之後主節點也將會降級為從節點，只接受讀，不再接受寫入。

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

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