MongoDB的複本集節點角色介紹及選舉過程淺析

MongoDB的複本集節點角色介紹及選舉過程淺析

一個複本集ReplicaSet一般由一組mongod執行個體組成，這組mongod執行個體協調配合工作，共同向外提供高可用的資料庫訪問服務。

複本集中的不同節點雖然都是mongod執行個體，但是角色上卻有不同，一般分為三種：主節點、副本節點和仲裁者節點。

主節點：負責所有的資料庫寫操作，預設情況下，主節點也負責處理所有的資料庫讀操作；

副本節點：負責同步主節點的資料動作記錄更新本機資料庫，從而保證副本節點的資料和主節點上的資料的一致性；副本節點的從某種意義上來講有點像賽跑，永遠在追趕主節點的資料操作；

仲裁節點：不負責儲存具體的資料，只是在複本集進行主節點選舉時提供自己的一個選票而已。

除了上面三個角色的節點外，還有幾種其他節點，下面簡單描述一下：

Secondary-Only：和副本節點一樣儲存了主節點的資料副本，但是在任何情況下都成為不了Primary主節點；

Hidden：這種類型的節點對於用戶端程式是不可見的，同樣不能成為Primary主節點，但是可以參與投票；

Delayed：這種類型的節點可以通過人為的設定，可以指定一個時間來延遲從主節點同步資料，Delayed成員主要用於從一些誤操作中恢複舊資料，並且肯定不能成為主節點而且是Hidden的；

一般情況下，一個最小化的複本集由一個主節點、一個副本節點和一個仲裁節點群組成，但是在實際使用過程中，大多數採用的是由一個主節點和兩個副本節點群組成的。

一個最小化複本集的結構圖如下所示：

在中，複本集中的主節點負責處理來自用戶端的所有讀寫操作，並將所有的修改資料庫的操作以日誌Oplog的方式記錄在本地；副本節點按照一定的頻率主動非同步從主節點從不動作記錄並作用於自己原生資料庫上，從而保證副本節點和主節點的資料一致性。複本集中的各個節點之間每2秒進行一個心跳請求，看看複本集中的其他節點的狀態。

正常情況下，讀寫操作是操作在主節點上，寫操作我們是無法進行控制的，只能作用在主節點上，但是對於讀操作我們確實可以控制的（從副本節點上讀取資料，從而達到讀寫分離），這時候我們就需要瞭解ReadPreference了，下面簡單列下都有哪些模式可以供我們選擇：

（1）primary：預設，所有的讀操作都從主節點擷取；

（2）primaryPerferred：在大多數情境下直接從主節點進行讀操作，如果主節點讀操作不可用時，則從副本節點進行讀取；

（3）secondary：所有的讀操作都只從副本節點進行讀取；

（4）secondaryPreferred：在大多數情境下，讀操作都從副本節點進行讀操作，如果副本節點不可用，那麼考慮從主節點進行讀取；

（5）nearest：所有的讀操作從網路延遲最小的節點上進行讀操作；

上面的結構是一個最小化的複本集結構，可以對外提供高可用的資料庫訪問能力，但是當主節點崩潰後或者暫時不可用時，整個複本集會發生什麼呢？

（1）如果主節點發現自己和複本集中大多數節點無法串連時，為了保證資料一致性，會將自己降級為副本節點，從而阻止有操作對資料庫進行修改；

（2）如果主節點崩潰了不可用了，那麼複本集會內會進行一次選舉操作，重新選舉產生一個主節點；

關於選舉的過程如下所示：

中，主節點Primary假設不可用了，那麼另外兩個副本節點在發現與主節點無法進行心跳時（正常情況下，每個節點每2秒跟其他節點進行一次心跳測試，如果在10s內未收到對方節點的回複，那麼認為對方節點不可用），有資格成為主節點的副本節點就會向其他節點發起一個選舉提議，基本的意思就是“我覺得我能成為主節點，你覺得呢？”，而其他節點在收到選舉提議後會判斷下面幾個條件：

（1）複本集中是否有其他節點已經是primary了？

（2）自己的資料是否比請求成為主節點的副本節點上的資料更新？

（3）複本集中其他節點的資料是否比請求成為主節點的副本節點的資料更新？

如果上面三個條件中只要有一個條件滿足，那麼都會認為對方的提議不可行，於是返回一個返回包給請求節點說“我覺得你成為primary不合適，停止選舉吧!”，請求節點只要收到其他任何一個節點返回不合適，都會立刻停止選舉，並將自己保持在secondary角色；但是如果上面三個條件都不滿足，那麼就會在返回包中回複說“我覺得你可以^_^”，那麼此時請求包就會進入選舉的第二階段。請求節點會向其他節點發送一個確認的請求包，基本意思就是“我宣布自己是primary了，有人反對沒？”，如果在這次確認過程中其他節點都沒人反對，那麼請求節點就將自己升級為primary節點，所有節點在30秒內不再進行其他選舉投票決定；如果有節點此時認為請求節點不適合做primary，那麼請求節點在收到反對回複後會保持自己的節點角色依然是secondary。

至此，我們簡單的說了說複本集的各節點角色及複本集主節點的選舉過程，如果想詳細瞭解，還是需要看看Mongodb官網關於複本集的詳細描述，謝謝。

https://docs.mongodb.com/manual/core/replica-set-members/

更多MongoDB相關教程見以下內容：

CentOS 編譯安裝 MongoDB與mongoDB的php擴充

CentOS 6 使用 yum 安裝MongoDB及伺服器端配置

Ubuntu 13.04下安裝MongoDB2.4.3

MongoDB入門必讀(概念與實戰並重)

Ubunu 14.04下MongoDB的安裝指南

《MongoDB 權威指南》(MongoDB: The Definitive Guide)英文文字版[PDF]

Nagios監控MongoDB分區叢集服務實戰

基於CentOS 6.5作業系統搭建MongoDB服務

MongoDB 的詳細介紹：請點這裡
MongoDB 的：請點這裡

本文永久更新連結地址：