簡介
在 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 個從節點因為異常掛掉了，那麼叢集檢測之後主節點也將會降級為從節點，只接受讀，不再接受寫入。
官方推薦在副本集中有投票權的節點數量為奇數個，主要是為了避免出現腦裂（一個叢集被分成了多個叢集）的情況。