復制
甲副本集 MongoDB中是一組mongod其保持相同的數據集的過程。副本集提供冗余和 高可用性，並且是所有生產部署的基礎。本節介紹MongoDB中的復制以及副本集的組件和體系結構。本節還提供了與副本集相關的常見任務的教程。
冗余和數據可用性
復制提供冗余並提高 數據可用性。使用不同數據庫服務器上的多個數據副本，復制可提供一定程度的容錯能力，以防止丟失單個數據庫服務器。
在某些情況下，復制可以提供更大的讀取容量，因為客戶端可以將讀取操作發送到不同的服務器。在不同數據中心中維護數據副本可以提高數據本地性和分布式應用程序的可用性。您還可以維護其他副本以用於專用目的，例如災難恢復，報告或備份。
在MongoDB中復制
副本集是一組mongod維護相同數據集的實例。一個副本集包含多個數據承載節點和一個仲裁器節點（可選）。在數據承載節點中，只有一個成員被視為主要節點，而其他節點則被視為次要節點。
所述主節點接收所有的寫操作。副本集只能有一個能夠確認與 寫入有關的寫入的主數據庫。盡管在某些情況下，另一個mongod實例可能會暫時認為自己也是主要實例。 [1]主數據庫在其操作日志（即oplog）中記錄對其數據集的所有更改。有關主節點操作的更多信息，請參見“ 副本主集”。{ w: "majority" }
該次級復制初級的OPLOG和應用操作的數據集，使得次級數據集反映了主要的數據集。如果主要節點不可用，則符合條件的次要節點將進行選舉以自行選舉新的主要節點。有關輔助成員的更多信息，請參閱副本集輔助成員。
您可以將一個額外的mongod實例作為仲裁器添加到副本集 。仲裁者不維護數據集。仲裁程序的目的是通過響應其他副本集成員的心跳和選舉請求來維護副本集中的仲裁。由於仲裁器不存儲數據集，因此它是提供副本集仲裁功能的好方法，比具有數據集的功能齊全的副本集成員的資源成本低。如果您的副本集成員數為偶數，請添加仲裁程序以majority在主要選舉中獲得票數。仲裁器不需要專用硬件。有關仲裁器的更多信息，請參見副本集仲裁器。
異步復制
輔助節點復制主節點的操作日志，並將操作異步應用於其數據集。通過使次要節點的數據集反映主要節點的數據集，即使一個或多個成員失敗，副本集也可以繼續運行。
有關復制機制的更多信息，請參閱 副本集操作日志和副本集數據同步。
較慢的操作
從版本4.2（也從版本4.0.6開始可用）開始，副本集的輔助成員現在 記錄的oplog條目所花費的時間比慢操作閾值要長。這些緩慢的oplog消息會在組件下的文本中記錄為次要日志。這些慢操作日志條目僅取決於慢操作閾值。它們不依賴於日志級別（在系統級別或組件級別），配置級別或運行緩慢的采樣率。探查器不會捕獲緩慢的操作日志條目。diagnostic logREPLapplied op: <oplog entry> took <num>ms
復制延遲和流控制
復制滯后是指將主操作上的寫操作復制（即復制）到輔助上所花費的時間 。可以接受一些小的延遲時間，但是隨着復制滯后的增加會出現嚴重的問題，包括在主數據庫上增加緩存壓力。
從MongoDB 4.2開始，管理員可以限制主數據庫應用其寫入的速率，以將延遲保持在可配置的最大值以下。majority committedflowControlTargetLagSeconds
默認情況下，流量控制為enabled。
注意
為了啟用流控制，副本集/分片集群必須具有：featureCompatibilityVersion（FCV） of 4.2並讀取關注。也就是說，如果未啟用FCV 或禁用了多數讀功能，則啟用的流控制無效。majority enabled4.2
啟用流量控制后，隨着滯后時間逐漸接近 flowControlTargetLagSeconds，主鎖上的寫操作必須先獲得票證，然后才能鎖定應用寫操作。通過限制每秒發出的票證數量，流控制機制嘗試將滯后保持在目標以下。
自動故障轉移
當主節點與集合中的其他成員的通信electionTimeoutMillis時間超過配置的時間段（默認為10秒）時，合格的輔助節點將要求選舉以提名自己為新的主節點。群集嘗試完成新主數據庫的選擇並恢復正常操作。
副本集無法處理寫入操作，直到選舉成功完成。如果將副本集配置為在主副本處於脫機狀態時在次副本上運行，則副本集可以繼續提供讀取查詢 。
假設為default，則集群選擇新的主節點之前的中值時間通常不應超過12秒。這包括將主要節點標記為不可用並致電並完成選舉所需的時間。您可以通過修改復制配置選項來調整此時間段 。網絡延遲之類的因素可能會延長完成副本集選舉所需的時間，進而影響您的群集在沒有主數據庫的情況下可以運行的時間。這些因素取決於您的特定群集體系結構。replica configuration settingssettings.electionTimeoutMillis
將electionTimeoutMillis 復制配置選項從默認值10000（10秒）降低可導致更快地檢測主要故障。但是，由於臨時網絡等待時間等因素，群集可能會更頻繁地調用選舉，即使主節點處於其他狀態也是如此。這可能會導致增加回滾為 寬：1次的寫操作。
您的應用程序連接邏輯應包括對自動故障轉移和后續選舉的容忍度。從MongoDB 3.6開始，MongoDB驅動程序可以檢測到主數據庫的丟失，並可以一次自動 重試某些寫入操作，從而提供了自動故障轉移和選擇的其他內置處理：
- 與MongoDB 4.2兼容的驅動程序默認情況下啟用可重試寫入
- MongoDB 4.0和3.6兼容的驅動程序必須通過
retryWrites=true在連接字符串中包含來顯式啟用可重試的寫入。
要了解有關MongoDB的故障轉移過程的更多信息，請參閱：
讀取操作
讀取首選項
默認情況下，客戶端從主服務器[1]讀取數據；但是，客戶端可以指定讀取首選項，以將讀取操作發送到輔助對象。
異步復制到輔助數據庫意味着從輔助數據庫讀取數據可能會返回不反映主數據庫上數據狀態的數據。
包含讀取操作的多文檔事務必須使用讀取首選項primary。給定事務中的所有操作都必須路由到同一成員。
有關從副本集讀取的信息，請參見“ 讀取首選項”。
數據可見性
根據讀取的關注點，客戶端可以在持久寫入之前看到寫入結果：
- 不管寫的寫關注點如何，其他使用
"local"或"available"讀關注的客戶端都可以在向發布客戶端確認寫操作之前看到寫操作的結果。 - 使用
"local"或"available"讀取關注點的客戶端可以讀取數據，這些數據隨后可能會在副本集故障轉移期間回滾。
對於多文檔事務中的操作，在提交事務時，將保存在事務中進行的所有數據更改，並在事務外部可見。也就是說，一個事務在回滾其他事務時將不會提交其某些更改。
在提交事務之前，在事務外部看不到在事務中進行的數據更改。
但是，當一個事務寫入多個分片時，並非所有外部讀取操作都需要等待已提交事務的結果在所有分片上可見。例如，如果提交了一個事務，並且在分片A上可以看到寫1，但是在分片B上仍然看不到寫2，則外部讀處於讀關注狀態 "local"可以讀取寫1的結果而看不到寫2。
有關MongoDB的讀取隔離，一致性和新近度的更多信息，請參閱讀取隔離，一致性和新近度。
交易
從MongoDB 4.0開始，多文檔事務可用於副本集。
包含讀取操作的多文檔事務必須使用讀取首選項primary。給定事務中的所有操作都必須路由到同一成員。
在提交事務之前，在事務外部看不到在事務中進行的數據更改。
但是，當一個事務寫入多個分片時，並非所有外部讀取操作都需要等待已提交事務的結果在所有分片上可見。例如，如果提交了一個事務，並且在分片A上可以看到寫1，但是在分片B上仍然看不到寫2，則外部讀處於讀關注狀態 "local"可以讀取寫1的結果而看不到寫2。
更改流
從MongoDB 3.6開始，更改流可用於副本集和分片群集。更改流允許應用程序訪問實時數據更改，而不會帶來復雜性和拖延操作日志的風險。應用程序可以使用更改流來訂閱一個或多個集合上的所有數據更改。
附加功能
副本集提供了許多選項來支持應用程序需求。例如，您可以在多個數據中心中部署具有成員的副本集，或通過調整members[n].priority某些成員的數量來控制選舉的結果 。副本集還支持專用成員進行報告，災難恢復或備份功能。
有關更多信息，請參見優先級0副本集成員， 隱藏副本集成員和 延遲副本集成員。
| [1] | （1，2）在某些情況下，副本集中的兩個節點可能暫時相信他們是主要的，但最多，其中一人將能夠完全寫入的寫入關注。可以完成 寫入操作的節點是當前主節點，另一個節點是以前的主節點，由於網絡分區，該主節點尚未意識到其降級。發生這種情況時，盡管求讀取首選項，但連接到前主數據庫的客戶端可能仍會觀察到過時的數據 ，並且對前主數據庫的新寫入最終將回滾。{ w: "majority" }{ w: "majority" }primary |
參考：https://docs.mongodb.com/manual/replication/