關於複製，你瞭解多少（附副本集常見任務教程）

時間 2021-06-16

標籤 redis mongodb 數據庫緩存服務器網絡架構 oracle app 運維欄目 Redis 简体版

原文原文鏈接

MongoDB Manual (Version 4.2）> Replicationredis

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

_No__1 _冗餘和數據

複製提供了冗餘並增長了數據可用性。對於不一樣數據庫服務器上的多個數據副本，複製爲防止單臺數據庫服務器故障提供了必定程度的容錯能力。數據庫

在某些狀況下，複製能夠提升讀取性能，由於客戶端能夠將讀操做發送到不一樣的服務器上。在不一樣的數據中心維護數據副本能夠提升分佈式應用程序的數據本地化和可用性。您還能夠維護額外的副本以實現特殊用途，好比災難恢復、報告或備份。緩存

_No__2_MongoDB的複製

副本集是一組維護相同數據集合的mongod實例。副本集包含多個數據承載節點和一個可選的仲裁節點。在數據承載節點中，有且僅有一個成員爲主節點，其餘節點爲副本節點。服務器

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

副本節點複製主節點的oplog，並將這些操做應用於它們的數據集，這樣以便副本節點的數據集能反映出主節點的數據集。若是主節點不可用，一個候選的副本節點將會發起選舉並使之成爲新的主節點。有關副本成員的更多信息，請參見副本集副本成員。架構

在某些狀況下(好比您有一個主節點和一個副本節點，但因爲成本約束沒法添加另外一個副本節點)，您能夠選擇將一個 mongod 實例做爲仲裁節點添加到一個副本集中。仲裁節點參與選舉但不持有數據(即不提供數據冗餘)。有關仲裁節點的更多信息，請參見副本集仲裁節點。oracle

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

_No__3_異步複製

副本節點複製主節點的oplog並異步地應用操做到它們的數據集。經過讓副本節點的數據集反映主服務器的數據集，副本集能夠在一個或多個成員失敗的狀況下繼續運行。運維

有關複製機制的更多信息，請參見副本集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)才能夠獲取寫鎖。經過限制每秒發出的許可單的數量，流控制機制能夠將延遲保持在目標數值之下。

爲獲取更多信息，請參見檢查複製延遲和流控制。

_No__4_自動故障轉移

當主節點沒法和集羣中其餘節點通訊的時間超過參數electionTimeoutMillis配置的期限時（默認10s），一個候選的副本節點會發起選舉來推薦本身成爲新主節點。集羣會嘗試完成一次新主節點的選舉並恢復正常的操做。

副本集在選舉成功前是沒法處理寫操做的。若是讀請求被配置運行在副本節點上，則當主節點下線時，副本集能夠繼續處理這些請求。

假設採用默認的副本配置選項，集羣選擇新主節點的中間過渡時間一般不該超過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。

_No__6_事務

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

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

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

_No__7_變動流

從MongoDB 3.6開始，副本集和分片集羣支持變動流。變動流容許應用程序訪問實時數據更改，而不須要跟蹤oplog的複雜性和風險。應用程序可使用變動流來訂閱一個或多個集合上的全部數據更改。

_No__8_附加功能

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

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

注意：

(1, 2) 在某些場景下, 一個複製集中的兩個節點可能會認爲它們是主節點，但最多，他們中的一個將可以完成寫關注點爲{ w: 「majority」 }寫操做。能夠完成 { w: 「majority」 } 寫的節點是當前主節點，而另外一個節點是原先的主節點，一般是因爲網絡分區致使它尚未意識到本身的降級。當這種狀況發生時，鏈接到原先主節點的客戶端儘管已經請求了讀偏好primary，但可能還會觀察到過期的數據，而且對原先主節點新寫的操做最終將回滾掉。