[mongo] {第六部分} mongodb replication V1

復制

MongoDB中副本集是一組mongod進程，其保持相同的數據集。副本集提供了冗余和?高可用性，并且是生產部署的基礎。

冗余和數據高可用性

復制提供冗余并提高?數據可用性。使用不同數據庫服務器上的多個數據副本，復制可提供一定程度的容錯能力，以防止單個數據庫服務器故障。

在某些情況下，復制可以提供更大的讀取容量，因為客戶端可以將讀取操作發送到不同的服務器。在不同數據中心中維護數據副本可以提高數據本地性和分布式應用程序的可用性。您還可以維護其他副本以用于專用目的，例如災難恢復，報表或備份。

MongoDB復制

replica set是一組mongod維護相同數據集的實例。一個副本集包含多個數據承載節點和一個仲裁器節點（可選）。在數據承載節點中，只有一個成員被視為主要節點，而其他節點則被視為次要節點。

Replica Set Members

Primary：主服務器接收所有寫操作。

Secondaries.輔助數據庫從主數據庫復制操作以維護相同的數據集。輔助服務器可能具有用于特殊用途配置文件的其他配置。例如，次級可以是?無表決權或?優先級0。

副本集的最低建議配置是具有三個數據承載成員的三個成員副本集：一個主要成員和兩個次要成員。在某些情況下（例如，您有一個主服務器和一個輔助服務器，但由于成本限制，禁止添加另一個輔助服務器），您可以選擇包括一個仲裁節點。仲裁節點加選舉，但不保存數據（即不提供數據冗余）。

一個副本集最多可以有50個成員，但只有7個投票成員。

Primary

主節點接收所有寫操作。一個副本集只能有一個主副本，能夠確認具有{w: majority}寫關注點的寫操作；盡管在某些情況下，另一個mongod實例可能會暫時認為自己也是主副本。[1] 主服務器在其操作日志（即oplog）中記錄對其數據集的所有更改。

Secondaries

二級數據庫復制主數據庫的oplog并將操作應用于它們的數據集，以便二級數據庫的數據集反映主數據庫的數據集。如果不可用，一個可用的secondary?將選舉自己成為新的primary節點。

不能成為primary和參與?選舉。

隱藏成員維護主數據集的副本，但對客戶端應用程序是不可見的。隱藏成員適用于使用模式與副本集中其他成員不同的工作負載。隱藏成員必須始終是優先級為0的成員，因此不能成為primary。

db.isMaster()

不顯示隱藏成員。然而，隱藏成員可以在選舉中投票。

延遲的成員包含副本集數據集的副本。但是，延遲成員的數據集反映了該集的較早或延遲的狀態。例如，如果當前時間是09:52，并且成員有一個小時的延遲，則延遲的成員沒有比08:52更新的操作。

由于延遲成員是數據集的“滾動備份”或運行中的“歷史”快照，因此它們可以幫助從各種人為錯誤中恢復。例如，延遲成員可以從失敗的應用程序升級和操作員錯誤（包括刪除的數據庫和集合）中恢復。

延遲成員：

必須是?優先級為0的?成員。將優先級設置為0，以防止延遲成員成為主要成員。

應該是?隱藏?成員。始終阻止應用程序查看和查詢延遲的成員。

如果members[n].votes設置為1?，可以進行投票。

Arbiter

在某些情況下（例如您有一個主服務器和一個輔助服務器，但由于成本限制，禁止添加另一個輔助服務器），您可以選擇將一個mongod實例作為仲裁節點添加到副本集?。仲裁節點參加?選舉，但不保存數據（即不提供數據冗余）。

仲裁節點不可成為主節點。

Replica Set Oplog

OPLOG（操作日志）是一個特殊的固定集合（capped collection），它可將修改數據的所有操作的滾動記錄存儲在數據庫中。

在版本4.0中進行了更改：從MongoDB 4.0開始，與其他固定集合不同，oplog可以增長超過其配置的大小限制，以避免刪除大多數提交點。

版本4.4中的新增功能：?MongoDB 4.4支持指定以小時為單位的最小oplog保留期限，其中MongoDB僅在以下情況下刪除oplog條目：

操作日志已達到配置的最大大小，并且

oplog條目早于配置的時間。

MongoDB在主數據庫上應用數據庫操作，然后在主數據庫的操作日志中記錄該操作。然后，輔助成員將這些操作復制并應用到異步過程中。所有副本集成員在local.oplog.rs集合中都包含操作日志的副本?，這使他們可以維護數據庫的當前狀態。

為了促進復制，所有副本集成員都將心跳（ping）發送給所有其他成員。任何輔助成員都可以從任何其他成員導入操作日志條目。

oplog中的每個操作都是冪等的。也就是說，oplog操作會產生相同的結果，無論是一次還是多次應用于目標數據集。

Oplog大小

首次啟動副本集成員時，如果未指定操作日志大小，則MongoDB會創建默認大小的操作日志。[1]

對于Unix和Windows系統

默認操作日志大小取決于存儲引擎：

儲存引擎

默認Oplog大小

下界

上界

In-Memory 存儲引擎

物理內存的5％

50MB

50 GB

WiredTiger存儲引擎

可用磁盤空間的5％

990MB

50 GB

對于64位macOS系統

默認操作日志大小為192 MB的物理內存或可用磁盤空間，具體取決于存儲引擎：

儲存引擎

默認Oplog大小

In-Memory存儲引擎

192 MB的物理內存

WiredTiger存儲引擎

192 MB的可用磁盤空間

在大多數情況下，默認操作日志大小已足夠。例如，如果操作日志是可用磁盤空間的5％，并且在24小時的操作中已滿，則輔助服務器可以在長達24小時的時間內停止從操作日志中復制條目，而不會過時而無法繼續復制。但是，大多數副本集的操作量要低得多，并且它們的oplog可以容納更多的操作。

在mongod創建操作日志之前，您可以使用oplogSizeMB選項指定其大小。首次啟動副本集成員后，請使用?replSetResizeOplog管理命令更改操作日志大小。replSetResizeOplog使您能夠動態調整操作日志的大小，而無需重新啟動mongod進程。

4.4版的新功能：從MongoDB 4.4開始，您可以指定保留oplog條目的最小時間。該mongod只截斷的OPLOG項，如果：

操作日志已達到配置的最大大小，并且

根據主機系統時鐘，oplog條目比配置的小時數早。

默認情況下，MongoDB不會設置最小操作日志保留期限，而是從最早的條目開始自動截斷操作日志，以維持配置的最大操作日志大小。

4.4版的新功能：從MongoDB 4.4開始，您可以指定保留oplog條目的最小時間。mongod僅移除一個OPLOG，如果：

操作日志已達到最大配置大小，并且

根據主機系統時鐘，oplog條目比配置的小時數早。

默認情況下，MongoDB不會設置最小操作日志保留期限，而是從最早的條目開始自動截斷操作日志，以維持配置的最大操作日志大小。

要在啟動時配置最小操作日志保留期?mongod，請執行以下任一操作：

將oplogMinRetentionHours設置添加到配置文件。

-要么-

添加--oplogMinRetentionHours命令行選項。

要在運行中配置最小oplog保留期限?mongod，請使用replSetResizeOplog。在mongod?運行時設置最小oplog保留期限將覆蓋啟動時設置的所有值。您必須更新相應的配置文件設置或命令行選項的值，以通過服務器重新啟動來保留這些更改。

的工作負載大需要較大Oplog

如果您可以預測副本集的工作量類似于以下模式之一，則可能需要創建一個大于默認值的操作日志。相反，如果您的應用程序主要以最少的寫操作執行讀取，則較小的操作日志可能就足夠了。

以下工作負載可能需要更大的oplog大小。

操作日志必須將多次更新轉換為單獨的操作，以保持冪等性。這會占用大量操作日志空間，而不會相應增加數據大小或磁盤使用量。

如果刪除與插入時大致相同的數據量，則數據庫在磁盤使用方面不會顯著增長，但是操作日志的大小可能會很大。

如果工作量的很大一部分是不增加文檔大小的更新，則數據庫會記錄大量操作，但不會更改磁盤上的數據量。

Oplog狀態

要查看操作日志狀態，包括操作的大小和時間范圍，請發出該rs.printReplicationInfo()方法。

數據同步

慢操作

從版本4.2開始（也可從4.0.6開始使用），副本集的輔助成員現在會記錄需要比慢速操作閾值更長時間才能應用的oplog條目。這些慢oplog消息記錄在REPL組件下的診斷日志中，并帶有文本applied op:takems。這些慢oplog條目僅取決于慢操作閾值。它們不依賴于日志級別（系統或組件級別）、分析級別或慢操作采樣率。探查器不會捕獲較慢的oplog條目。

復制延遲和流控制

復制延時是指將主磁盤上的寫操作復制到輔助節點上的時間?。可以接受一些小的延遲時間，但是隨著復制延時的增加會出現嚴重的問題，包括在主數據庫上增加緩存壓力。

從MongoDB 4.2開始，管理員可以限制主應用其寫入的速率，目的是將大多數提交的延遲保持在可配置的最大值flowControlTargetLagSeconds下。

默認情況下，流控制為enabled。

注：要啟用流控制，副本集/分片群集必須：featureCompatibilityVersion（FCV）是4.2版本及開啟read concern majority。也就是說，如果FCV不是4.2或者如果read concern majority被禁用，那么流控制將不起作用。

在啟用流控制的情況下，隨著延遲接近flowControlTargetLagSeconds，主服務器上的寫操作必須在獲取鎖以應用寫操作之前獲取tickets。通過限制每秒發行的tickets數量，流控制機制試圖將延遲保持在目標值以下。

異步復制

輔助節點復制主節點的操作日志，并將操作異步應用于其數據集。通過使輔助數據庫的數據集反映主要數據庫的數據集，即使一個或多個成員失敗，副本集也可以繼續運行。

自動故障轉移

當主節點與集合中的其他成員的通信electionTimeoutMillis時間超過配置的時間段（默認為10秒）時，可用的輔助節點將要求選舉以提名自己為新的主節點。群集嘗試完成新主數據庫的選擇并恢復正常操作。

副本集無法處理寫入操作，直到選舉成功完成。如果將副本集配置為在主副本處于脫機狀態時在次副本上運行，則副本集可以繼續提供讀取查詢?。

假設默認的副本配置設置，集群選擇新主服務器之前的平均時間通常不應超過12秒。這包括將初選標記為不可用、調用和完成選舉所需的時間。您可以通過修改settings.electionTimeoutMillis設置復制配置選項。諸如網絡延遲之類的因素可能會延長完成副本集選擇所需的時間，進而影響群集在沒有主服務器的情況下運行的時間。這些因素取決于特定的集群體系結構。

將electionTimeoutMillis復制配置選項從默認值10000（10秒）降低可以更快地檢測主故障。然而，由于諸如臨時網絡延遲之類的因素，集群可能更頻繁地調用選舉，即使主節點在其他方面是健康的。這可能導致w:1寫操作的回滾增加。

應用程序連接邏輯應包括對自動故障切換和后續選擇的容忍度。從MongoDB 3.6開始，MongoDB可以檢測到主設備的丟失，并自動重試某些寫入操作一次，從而提供自動故障切換和選擇的額外內置處理：

與MongoDB 4.2兼容的驅動程序默認情況下啟用重試寫入

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

從4.4版開始，MongoDB提供鏡像讀取，以使用最近訪問的數據預熱可選舉的次要成員的緩存。預熱輔助服務器的緩存可以幫助在選舉后更快地恢復性能。

Write Concern

副本集的Write concern描述了在操作返回成功之前必須確認寫操作的數據承載成員（即主要成員和次要成員，但不是仲裁節點）的數量。成員只能在成功接收并應用寫操作之后才確認寫操作。

對于副本集，w:1的默認Write concern要求只有主副本集成員在返回寫入關注點確認之前確認寫入。您可以指定一個大于1的整數值，以要求主副本進行確認，并根據需要指定多個輔助副本來滿足指定的值，最多為副本集中承載數據的成員總數。

Write concern為“majority”的寫入操作要求確認寫入操作已傳播到數據承載投票成員的計算多數。對于成員已啟用日志記錄的集群，將“majority” Write concern與j:true結合可以防止Write concern確認后的數據的回滾。

讀取操作

Read Preference

默認情況下，應用程序將其讀取操作定向到副本集中的??primary?成員（即讀取首選項模式“?primary?”）。但是，客戶端可以指定讀取首選項，以將讀取操作發送到輔助對象。

讀取首選項模式

描述

primary

默認模式。所有操作均從當前副本集primary中讀取?。

包含讀取操作的多文檔事務必須使用讀取首選項primary。給定事務中的所有操作都必須路由到同一成員。

primaryPreferred

在大多數情況下，操作從主服務器讀取，但如果不可用，則從輔助?成員讀取操作。

從版本4.4開始，primaryPreferred支持分片?群集上的樹籬讀取。

secondary

所有操作均從副本集的輔助成員讀取。

從版本4.4開始，secondary支持分片?群集上的樹籬讀取。

secondaryPreferred

在大多數情況下，操作從輔助?成員讀取，但是如果沒有輔助成員可用，則操作從分片群集的主成員讀取。

從版本4.4開始，secondaryPreferred支持分片?群集上的樹籬讀取。

nearest

基于指定的等待時間閾值，從隨機的合格副本集?成員讀取操作，而不管該成員是主要副本?還是次要副本。該操作在計算延遲時會考慮以下因素：

在localThresholdMS連接字符串選項

該maxStalenessSeconds閱讀偏好選項

任何指定的標簽集

從版本4.4開始，nearest支持分片?群集上的樹籬讀取，并且默認情況下啟用樹籬讀取選項。

異步復制到輔助數據庫意味著從輔助數據庫讀取數據可能會返回不反映主數據庫上數據狀態的數據。

多文檔事務的讀取必須使用read preference?primary。給定事務中的所有操作都必須路由到同一成員。

數據可見性

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

不管?write concern，其他使用"local"或"available"?read concern的客戶端都可以在向發布客戶端確認寫操作之前看到寫操作的結果。

使用"local"或"available"?read concern的客戶端可以讀取數據，這些數據隨后可能會在副本集故障轉移期間回滾。

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

在提交事務之前，在事務外部看不到在事務中進行的數據更改。

但是，當一個事務寫入多個分片時，并非所有外部讀取操作都需要等待提交的事務的結果在分片中可見。例如，如果事務已提交，并且write 1在shard a上可見，但write 2在shard B上尚不可見，則外部read concern “local”可以讀取write 1的結果，而不會看到write 2。

鏡像讀取

從版本4.4開始，MongoDB提供鏡像讀取來預熱可選輔助成員（即優先級大于0的成員）的緩存。使用鏡像讀取（默認情況下啟用），主服務器可以鏡像它接收的操作子集，并將它們發送到可選擇的輔助服務器子集。子集的大小是可配置的。

注意：

主服務器對客戶端的響應不受鏡像讀取的影響。鏡像讀取是由主服務器執行的“fire-and-forget”操作；即，主服務器不等待鏡像讀取的響應。

以下操作支持鏡像讀取：

count

distinct

find

findAndModify?（特別是，過濾器作為鏡像讀取發送）

update?（特別是，過濾器作為鏡像讀取發送）

在MongoDB 4.4中，默認情況下啟用鏡像讀取，并使用默認采樣率0.01。也就是說，主鏡像以1%的采樣率讀取每個可選（即優先級大于0）次鏡像。

例如，給定一個副本集，該副本集有一個主副本和兩個可選的輔助副本，采樣率為0.01，如果主副本接收到100個可以鏡像的操作，則采樣可能導致1個讀取鏡像到一個輔助副本，0個讀取鏡像到另一個副本，或0個讀取鏡像到每個副本，以此類推。

要修改采樣率，請使用mirrorReads參數：

采樣率值0.0禁用鏡像讀取。

大于0.0啟用鏡像讀取的采樣率。

采樣率不能大于1.0。

從MongoDB 4.4開始，如果您在操作中指定了字段的包含內容，則該命令serverStatus及其相應的mongoshell方法將?db.serverStatus()返回mirroredReads。例如，

db.serverStatus( { mirroredReads: 1 } )

事務

從MongoDB 4.0開始，多文檔事務可用于副本集。

多文檔事務的讀取必須使用read preference?primary。給定事務中的所有操作都必須路由到同一成員。

在提交事務之前，在事務外部看不到在事務中進行的數據更改。

但是，當一個事務寫入多個分片時，并非所有外部讀取操作都需要等待提交的事務的結果在分片中可見。例如，如果事務已提交，并且write 1在shard a上可見，但write 2在shard B上尚不可見，則外部read concern “local”可以讀取write 1的結果，而不會看到write 2。

Change Streams

從MongoDB 3.6開始，change streams可用于副本集和分片群集。change streams允許應用程序訪問實時數據更改，而不會帶來復雜性和拖延操作日志的風險。應用程序可以使用change streams來訂閱一個或多個集合上的所有數據更改。

附加功能

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

rs.status（）

從運行方法的成員的角度返回副本集狀態。此方法為replSetGetStatus命令提供了包裝?。

此輸出使用從副本集其他成員發送的心跳數據包派生的數據反映副本集的當前狀態。

MongoDB 云數據庫 GaussDB(for Mongo) 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。