monogdb複製原理詳解

標籤：mongodb複製集原理講解

一、複製介紹

複製是在多台伺服器之間同步資料的過程。

 

複製在為資料提供了冗餘同時，也提高了資料的可用性。由於在不同的資料庫伺服器上擁有多個資料鏡像，複製可以有效防止由於單台伺服器故障而導致的資料丟失。複製還能夠協助我們從硬體故障或是服務中斷中恢複資料。我們也可以通過增加複製節點來將其用於災難恢複、報表或是備份。

在某些情況中，我們可以通過複製的方式來提高讀的效能。用戶端可以將讀與寫請求分別發送到不同的伺服器上。我們還能夠通過在其他資料中心建立分布式複製節點的方式來做異地冗災，以進一步提高可用性。

 

MongoDB中的複製

複製集是由一組擁有相同資料集的 mongod 執行個體組成的。其中的一個節點為主節點（Primary），所有的寫請求都是在它上面完成的。而其他的節點都是從節點（secondary），從節點接收從主節點上傳來的操作並應用，並以此來保證其與主節點的資料集一致。

 

主節點 接收所有來自用戶端的寫操作。一個複製集只能有一個主節點。由於在一個複製集中只有一個成員能夠接收寫操作，複製集為所有來自主節點的讀提供了 嚴格的一致性校正 。主節點通過將所有資料集的變動記錄到 oplog 中以支援複製的實現。

650) this.width=650;" src="http://docs.mongoing.com/manual/_images/replica-set-read-write-operations-primary.png" alt="replica-set-read-write-operations-primar" />

 

從節點 將主節點上的oplog複製過來並應用這些操作來修改其自己的資料集以確保從節點的資料集與主節點的資料集一致。一旦主節點不可用了，複製集就會將一個從節點選舉成為新的主節點。用戶端預設是從主節點進行讀操作，但是用戶端也可以通過指定 複製集讀選項 來將讀操作發送給從節點。需要注意的是，在從節點上進行讀操作時，所獲得的資料可能不是此時主節點上的值

650) this.width=650;" alt="Diagram of a 3 member replica set that consists of a primary and two secondaries." src="http://docs.mongoing.com/manual/_images/replica-set-primary-with-two-secondaries.png" />

 

我們也可以為複製集新增一個額外的 mongod 執行個體作為 投票節點 。投票節點中並不包含資料集，投票節點的作用僅僅是在選舉過程中參與投票。當複製集的成員個數為偶數時，添加一個投票節點可以防止平局的出現，通過多數選票來選舉出新的主節點。由於投票節點僅提供投票功能，故無需一個專用的物理機。

650) this.width=650;" alt="Diagram of a replica set that consists of a primary, a secondary, and an arbiter." src="http://docs.mongoing.com/manual/_images/replica-set-primary-with-secondary-and-arbiter.png" />

 

投票節點 將只做投票使用。當 主節點 降職變為 從節點 的時候，其他的一個 從節點 將在選舉中被推選為主節點。

 

非同步複製

從節點從主節點上應用操作的過程是非同步。由於從節點是在主節點之後應用操作的，所以複製集在缺少某些成員的時候仍能繼續運行。然而在這種情況下，從節點返回給用戶端的資料可能並不是最新的資料。

 

自動化故障切換

當主節點無法與複製集中其他成員進行溝通超過10秒時，複製集將嘗試推舉另一位成員成為新的主節點。這時，第一個獲得多數投票的從節點將升職為主節點。

650) this.width=650;" alt="Diagram of an election of a new primary. In a three member replica set with two secondaries, the primary becomes unreachable. The loss of a primary triggers an election where one of the secondaries becomes the new primary" src="http://docs.mongoing.com/manual/_images/replica-set-trigger-election.png" />

 其他特徵

複製集提供了一些選項來支援實際應用時的需求。例如，將一個複製集分布在多個資料中心 ，又或是通過設定 priority 來控制選舉的結果。複製集同時也支援將成員用於報表、災難恢複或是備份。

 

二、複製概念介紹複製整合員

MongoDB的 複製集 是由一組 mongod 執行個體所組成的，並提供了資料冗餘與高可用性。複製集中的成員有以下幾種：

• Primary.

• 主節點 接收所有的寫操作請求。

• Secondaries.

• 從節點通過應用主節點傳來的資料變動操作來保持其資料集與主節點的一致。從節點也可以通過增加額外的參數配置來對應特殊的需求。例如，從節點可以是 non-voting 或是 priority 0 。

我們也可以為複製集設定一個 投票節點 。投票節點其本身並不包含資料集。但是，一旦當前的主節點不可用時，投票節點就會參與到新的主節點選舉的投票中。

一個複製集最多可以擁有12個成員。 [1] 但是同時最多隻有其中的7個可以進行投票。

一個複製集至少需要這幾個成員：一個 主節點 ，一個 從節點 ，和一個 投票節點 。但是在大多數情況下，我們會保持3個擁有資料集的節點：一個 主節點 和兩個 從節點 。

 

複製集主節點

在複製集中，主節點是唯一能夠接收寫請求的節點。MongoDB在 主節點 上進行寫操作，並會將這些操作記錄到主節點的 oplog 中。 從節點 會將oplog複製到其本機並將這些操作應用到其自己的資料集上。

在擁有下述三個成員的複製集中，主節點將接收所有的寫請求，而從節點會將oplog複製到本機並在其自己的資料集上應用這些操作。

 

複製集中任何成員都可以接收讀請求。但是預設情況下，應用程式會直接連接到在主節點上進行讀操作。

 

複製集最多隻能擁有一個主節點。一旦當前的主節點不可用了，複製集就會選舉出新的主節點。

 

在擁有下述三個成員的複製集中，一旦當前主節點不可用了，就會觸發選舉機制，並將在剩下的從節點中選舉出一個新的主節點。

 

複製集從節點

從節點的資料集與 主節點 中的一致。從節點將主節點上的 oplog 複製到本機，並非同步將這些操作記錄應用在其自己的資料集上。每個複製集可以擁有多個從節點。

下述由三個成員組成的複製集擁有兩個從節點。這些從節點將主節點上的oplog複製過來並應用在其自己的資料集上。

 

用戶端雖然無法在從節點上進行寫操作，但卻可以進行讀操作。

從節點是可以升職為主節點的。一旦現有的主節點不可用了，那麼複製集將會發起 election 來選擇將哪個從節點提升為新的主節點。

在擁有下述三個成員的複製集中，一旦當前主節點不可用了，就會觸發選舉機制，並將在剩下的從節點中選舉出一個新的主節點。

 

我們可以通過修改參數的方式來將從節點用於特殊的需求。例如：

• 我們可以通過禁止從節點升職為主節點的方式來將該節點永駐為從節點或是用於冷備。

• 我們可以通過禁止應用在該從節點上進行讀操作的方式，來讓一些需要進行流量隔離的應用在其上進行讀。

• 我們可以通過設定 “延時備份節點” 的方式來防止諸如誤刪除等的誤操作或是錯誤。

 

優先順序為0的複製整合員

一旦將優先順序設定為0，那麼該從節點將 不能 升職為 主節點 。 優先順序為0 的成員不會 觸發 選舉 。除此之外該節點與其他從節點沒有區別，優先順序為0 的從節點擁有與主節點一致的資料集，能接受讀請求，同時也能參與投票。通過將從節點的 優先順序設定為0 來防止其升職為主節點可以在分布式資料中心的結構中起到很好的作用。

在下述這樣的擁有三個成員的複製集中，一個主節點和一個從節點坐落在某一個資料中心中，另一個不能升職為主節點的 優先順序為0 的從節點則在另一個資料中心。

 

將優先順序為0的成員作為備用節點

在很多情況下，我們可能不需要準備一個 優先順序為0 的備用節點。然而在一些硬體環境或是架構的 地理分布 較為多變的情境中，一個 優先順序為0 的備用節點可以很好的保證合格成員升職為主節點。

一個擁有特殊硬體設定或是系統最佳化配置的 優先順序為0 的備用節點也可以有效為特殊需求提供服務。比如可以將 優先順序設定為0 來讓其不能升職為主節點。

如果我們的複製集中已經有了七個參與投票的節點，那麼請將其他節點設定為 不參與投票 。

 

優先順序為0的節點與故障切換

當配置一個 優先順序為0 的節點時，我們需要考慮到可能出現的故障切換情況，比如網路故障等。需要注意的時，我們要確保在主要資料中心中擁有足夠多可以參與投票和選舉的節點，並確保其擁有可以順利成為主節點的成員。

 

 

隱藏節點

隱藏節點擁有與 主節點 一致的資料集，但是它對於應用程式來說是 不可見 的。隱藏節點可以很好的與 複製集 中的其他節點隔離，並應對特殊的需求。隱藏節點也應該是一個 不能升職為主節點 的 優先順序為0的節點 。函數 db.isMaster() 將不會列出隱藏節點。隱藏節點在 選舉 中是 可以進行投票 的。

在下述這樣擁有五個節點的複製集中，四個從節點都擁有與主節點一致的資料集，但其中的一個從節點是隱藏節點。

 

讀操

用戶端將不會把讀請求分發到隱藏節點上，即使我們設定了 複製集讀選項 。這些隱藏節點將不會收到來自應用程式的請求。我們可以將隱藏節點專用於報表節點或是備份節點。 延時節點 也應該是一個隱藏節點。

在分區叢集中， mongos 將不與隱藏節點進行交流。

 

投票

在複製集的選舉中，隱藏節點是會 參加 投票的。當關閉一個隱藏節點的時候，請確認複製集中的可用節點個數足夠進行選舉，以防 主節點 降職導致複製集對外不可用。

將隱藏節點用於備份，可以防止我們在備份過程中使用 db.fsyncLock() 和 db.fsyncUnlock() 操作來對 mongod 執行個體加或解除寫鎖的過程中應用程式的不可用。

 

 

延時節點

延時節點也將從 複製集 中主節點複製資料，然而延時節點中的資料集將會比複製集中主節點的資料延後。舉個例子，現在是09：52，如果延時節點延後了1小時，那麼延時節點的資料集中將不會有08：52之後的操作。

由於延時節點的資料集是延時的，因此它可以協助我們在人為誤操作或是其他意外情況下恢複資料。舉個例子，當應用升級失敗，或是誤操作刪除了表和資料庫時，我們可以通過延時節點進行資料恢複。

 

行為

延時節點通過延時應用 oplog 中的操作來實現其延時的效果。當我們選擇延時時常的時候，需要考慮到以下內容：

• 必須大於或者等於你的維護視窗。

• 必須 小於 oplog的儲存能力

 

分區

在分區叢集中，當 平衡器 平衡器開啟的時候延時節點效果有限。因為延時節點延時的複製資料區段，而若在延時的時間段內進行過資料區段遷移的話，複製集中的延時節點就無法為還原分區叢集提供有效協助

 

例子

在下述這樣擁有五個成員的複製集中，主節點與所有從節點都擁有資料集的副本。其中一個從節點延時3600秒（1小時）應用oplog中的操作。這個延時節點同時也是 隱藏節點 和 優先順序為0 的節點。

 

配置方式

延時節點需要將 priority 設定為0，還需要將 hidden 設定為 true ，同時還需要將 slaveDelay 設定為想要延遲的時間（單位為秒）：

{   "_id" : <num>,   "host" : <hostname:port>,   "priority" : 0,   "slaveDelay" : <seconds>,   "hidden" : true}

 

投票節點

投票節點 並不含有 複製集中的資料集副本，且也 無法 升職為主節點。複製集中可能會有多個投票節點來為 選舉出新的主節點 進行投票。投票節點的存在使得複製集可以以偶數個節點存在，而無需為複製集再新增節點。

 

注意

不要將投票節點運行在複製集的主節點或者從節點機器上。

 

僅僅在複製整合員為偶數個的時候加入投票節點。如果在擁有奇數個複製整合員的複製集中新增了一個投票節點，複製集可能會遇到 選舉 僵局。

 

monogdb複製原理詳解