關于MongoDB復制，你了解多少（附副本集常見任務教程）

MongoDB中的副本集是一組維護相同數據集合的  mongod進程。副本集提供了冗余和高可用性，并且這是所有生產部署的基礎。本節介紹MongoDB中的復制以及副本集的組件和體系結構，并提供副本集常見任務的教程。

復制提供了冗余并增加了數據可用性。對于不同數據庫服務器上的多個數據副本，復制為防止單臺數據庫服務器故障提供了一定程度的容錯能力。

在某些情況下，復制可以提高讀取性能，因為客戶端可以將讀操作發送到不同的服務器上。在不同的數據中心維護數據副本可以提高分布式應用程序的數據本地化和可用性。您還可以維護額外的副本以實現特殊用途，比如災難恢復、報告或備份。

主節點 接收所有的寫操作。一個副本集僅有一個主節點能夠用 { w: "majority" } 寫關注點級別來確認寫操作；雖然在某些情況下，另一個mongod的實例也可以暫時認為自己是主節點。[1] 主節點會將其數據集合所有的變化記錄到操作日志中，即oplog。有關主節點操作的更多信息，請參見 副本集主節點。

副本節點復制主節點的oplog，并將這些操作應用于它們的數據集，這樣以便副本節點的數據集能反映出主節點的數據集。如果主節點不可用，一個候選的副本節點將會發起選舉并使之成為新的主節點。有關副本成員的更多信息，請參見副本集副本成員。

在某些情況下(比如您有一個主節點和一個副本節點，但由于成本約束無法添加另一個副本節點)，您可以選擇將一個  mongod 實例作為仲裁節點添加到一個副本集中。仲裁節點參與選舉但不持有數據(即不提供數據冗余)。有關仲裁節點的更多信息，請參見副本集仲裁節點。

仲裁節點永遠只能是仲裁節點，但在選舉過程中主節點也許會降級成為副本節點， 副本節點也可能會升級成為主節點。

有關復制機制的更多信息，請參見副本集Oplog和副本集數據同步。

從4.2版本開始（從4.0.6開始也是可行的），副本集的副本成員會記錄oplog中應用時間超過慢操作閾值的慢操作條目。這些慢oplog信息被記錄在副本節點的診斷日志中，其路徑位于 REPL 組件的文本 applied op: took ms中。這些慢日志條目僅僅依賴于慢操作閾值。它們不依賴于日志級別（無論是系統還是組件級別）、過濾級別，或者慢操作采樣比例。過濾器不會捕獲慢日志條目。

復制延遲 指的是將主節點的寫操作拷貝(即復制)到副本節點所花費的時間。一些小的延遲期可能是可以接受的，但是隨著復制延遲的增長，會出現嚴重的問題，包括引起主節點的緩存壓力。

從MongoDB 4.2開始，管理員可以限制主節點應用寫操作的速度，目的是將 majority committed 延遲保持在可配置參數 flowControlTargetLagSeconds的最大值之下。

默認情況下，流控制是啟用的。

注意：

為了進行流控制，復制集/分片集群必須滿足：參數featureCompatibilityVersion (FCV) 設置為 4.2并啟用majority讀關注點。也就是說，如果FCV不是  4.2 ，或者讀關注點majority被禁用，那么啟用流控制將不起作用。

啟用流控制后，當延遲快接近 flowControlTargetLagSeconds參數指定的秒數時，主節點上的寫操作必須首先獲得許可單（tickets)才可以獲取寫鎖。通過限制每秒發出的許可單的數量，流控制機制可以將延遲保持在目標數值之下。

為獲取更多信息，請參見檢查復制延遲和流控制。

副本集在選舉成功前是無法處理寫操作的。如果讀請求被配置運行在副本節點上，則當主節點下線時，副本集可以繼續處理這些請求。

假設采用默認的副本配置選項，集群選擇新主節點的中間過渡時間通常不應超過12秒。這包括了將主節點標記為unavailable、發起以及完成一次選舉的時間。您可以通過修改 settings.electionTimeoutMillis 復制配置選項來調整這個時間期限。網絡延遲等因素可能會延長完成副本集選舉所需的時間，從而影響您的集群在沒有主節點的情況下運行的時間。這些因素取決于您實際的集群架構情況。

將 electionTimeoutMillis復制配置選項從默認的 10000(10秒)降低可以更快地檢測主節點故障。然而，由于諸如臨時性的網絡延遲等因素，集群可能會更頻繁地發起選舉，即使主節點在其他方面是健康的。這也許會增加w : 1 級別寫操作發生回滾的可能性。

您的應用程序連接邏輯應該包括對自動故障轉移和后續選舉的容錯處理能力。從MongoDB 3.6開始，MongoDB驅動程序可以探測到主節點的丟失，并自動重試某些寫操作 一次，提供額外的自動故障轉移和選舉的內置處理:

• MongoDB 4.2兼容的驅動程序默認啟用可重試寫
• MongoDB 4.0和3.6兼容的驅動程序必須通過在 連接字符串中包含 retryWrites=true來顯式地啟用可重試寫。

請參見 副本集選舉來獲取副本集選舉的完整信息。

為了解更多關于MongoDB失敗處理的信息，請參見：

• 副本集選舉
• 可重試寫
• 副本集故障期間的回滾

No 5 讀操作

默認情況下，客戶端從主節點讀取[1]；然而，客戶端可以定義一個讀偏好 將讀操作發送給副本節點。

異步復制至副本節點，意味著從副本節點讀取返回的數據不能反映主節點上數據的狀態。

包含讀操作的多文檔事務必須使用讀偏好 primary。在給定的事務中所有操作都必須路由至相同的成員節點。

為了解更多關于副本集讀的信息，請參見讀偏好。

根據讀關注點，客戶端可以在寫持久化前看到寫結果：

• 不管寫的write concern級別是什么，其他使用了讀關注點級別為  "local" 或  "available" 的客戶端，可以在發起寫操作的客戶端確認其寫成功之前查看該客戶端寫的結果。
• 使用了讀關注點級別為  "local" 或  "available" 的客戶端，能讀取在副本集故障轉移期間可能隨后被回滾掉的數據。

對于多文檔事務中的操作，當事務提交時，在事務中所做的所有數據更改都會被保存并在事務外部可見。也就是說，事務在回滾其他更改時不會提交某些更改。

在事務提交之前，事務中所做的數據更改在事務外部是不可見的。

然而，當一個事務寫入多個分片時，并不是所有外部的讀操作都需要等待提交的事務的結果在分片中可見。例如，如果提交了一個事務，并且在分片a上可以看到寫1，但是在分片B上還不能看到寫2，那么外部讀關注點為  "local" 的讀可以在不看到寫2的情況下讀取寫1的結果。

更多請參見Read Isolation, Consistency, and Recency。

從MongoDB 4.0開始，副本集支持多文檔事務。

包含讀操作的多文檔事務必須使用讀偏好  primary。給定事務中所有的操作都必須路由至相同的成員節點。

在事務提交之前，事務中所做的數據更改在事務外部是不可見的。

然而，當一個事務寫入多個分片時，并不是所有外部的讀操作都需要等待提交的事務的結果在分片中可見。例如，如果提交了一個事務，并且在分片a上可以看到寫1，但是在分片B上還不能看到寫2，那么外部讀關注點為  "local" 的讀可以在不看到寫2的情況下讀取寫1的結果。

從MongoDB 3.6開始，副本集和分片集群支持變更流。變更流允許應用程序訪問實時數據更改，而不需要跟蹤oplog的復雜性和風險。應用程序可以使用變更流來訂閱一個或多個集合上的所有數據更改。

副本集提供了許多選項來支持應用程序的需求。例如，你可以使用多數據中心中的成員來部署一個副本集，或者通過調整一些成員的 members[n].priority 來控制選舉結果。副本集還支持用于報告、災難恢復或備份功能的專用成員。

更多有關信息請參見優先級0的副本集成員，隱藏副本集成員和延遲副本集成員 。

注意：

(1, 2) 在 某些場景下, 一個復制集中的兩個節點可能會認為它們是主節點，但最多，他們中的一個將能夠完成寫關注點為{ w: “majority” }寫操作。可以完成 { w: “majority” } 寫的節點是當前主節點，而另一個節點是原先的主節點，通常是由于網絡分區導致它還沒有意識到自己的降級。當這種情況發生時，連接到原先主節點的客戶端盡管已經請求了讀偏好primary，但可能還會觀察到過時的數據，并且對原先主節點新寫的操作最終將回滾掉。

譯者：李正洋

MongoDB中文社區翻譯小組成員

目前在傳統金融行業從事DBA職務，5年+工作經驗，主要負責公司oracle/mongodb/es/redis各類數據庫及數據中心監控平臺運維工作，oracle ocp，MongoDB認證專家，RHCE，現階段對開源分布式數據庫、云計算等領域有很大興趣；平時喜歡打羽毛球、看電影等。

原文鏈接：

https://docs.mongodb.com/manual/replication/