MongoDB複製選舉原理以及複製集的管理

MongoDB複製集的節點是經過選舉產生主節點的。

複製的原理：複製是基於操做日誌oplog，至關於MySQL的二進制日誌，只記錄發生改變的記錄。複製將主節點的oplog日誌同步並應用到其餘從節點的過程

選舉的原理：節點類型分爲標準節點，被動節點，仲裁節點。

                     （1）只有標準節點可能被選爲活躍（primary）節點,有選舉權。被動節點有完整副本，不可能成爲活躍節點，有選舉權。仲裁節點不復制數據，不可能成爲活躍節點，只有選舉權。

                     （2）標準節點與被動節點的區別：priority值高者是標準節點，低着則爲被動節點。

                     （3）選舉規則是票數高者獲勝，priority是優先權爲0-1000的值，至關於額外增長0-1000的票數。選舉結果：票數高者獲勝：若票數相同，數據新者獲勝

下圖爲MongoDB複製集節點間選舉的結構圖

 

下面我會經過幾個實驗來驗證複製集的選舉原理

 

1、 建立四個節點，端口分別爲27017，27018，27019，27020，其中27017和27018做爲標準節點，27019做爲被動節點，27020做爲仲裁節點

1 建立三個節點的數據存放路徑和日誌存放路徑，其中27017爲默認節點，因此不須要建立

 

2 對27017的配置文件進行更改，將能夠訪問的地址改成全部，同時開啓複製集模塊，將複製集名稱定爲kgcrs

 

3 第一個實例的配置文件改完以後複製三分，分別做爲剩下三個實例的配置文件，完成以後再逐個修改

 

4 對第二個實例的配置文件進行修改，其中須要定義好數據的存放路徑和日誌文件的存放路徑，接着將端口改成27018

 

4 接着更改第三個實例的配置文件，一樣要修改文件路徑，將端口改成27019

 

5 第四個實例將端口改成27020

 

6 開啓這四個實例

 

7 查看這四個實例的端口

 

 

二 驗證複製集的選舉原理

（1）配置複製集的優先級

1 進入第一個實例，配置四個節點的複製集，設置兩個標準節點，一個被動節點和一個仲裁節點

 

2 複製集配置完成後就能夠進行初始化

 

3 初始化完成後查看該複製集的狀態，能夠看到27017變爲了活躍節點，27018和27019變爲了從節點，最後的27020是仲裁節點

 

（2）模擬節點故障

1 關閉活躍節點

2 進入另外一個標準節點，能夠發現第二個標準節點成爲了活躍節點

3 接着我再關閉第二個標準節點

4 進入被動節點進行查看，能夠發現角色並無切換，依然是從節點

5 接着我再次將兩個標準節點打開

6 進入第一個標準節點進行查看，能夠發現它已經變成了活躍節點

最後總結：若是主節點出現故障，另外一個標準節點將會選舉成爲新的主節點，若是全部標準節點都出現故障，被動節點也不會成爲主節點

 

三 MongoDB複製集管理

（1）配置容許在從節點上讀取數據

默認MongoDB複製集的從節點不能讀取數據，能夠使用rs.slaveOK()命令容許可以在從節點讀取數據

1 在從節點上對數據庫進行查看時並不會顯示信息

2 執行rs.slaveOK()後再次進行查看即可以顯示了

 

（2）查看複製狀態信息

能夠使用rs.printReplicationInfo()和rs.printSlaveReplicationInfo()命令來查看複製集狀態

這裏rs.printReplicationInfo()能夠查看日誌文件的大小，rs.printSlaveReplicationInfo()會顯示有哪些節點會對數據進行復制，能夠看到這裏並無仲裁節點，由於仲裁節點不會複製數據

 

（3）更改oplog大小

oplog即operations log的簡寫，儲存在local數據庫中。oplog中新操做會自動替換舊的操做，以保證oplog不會超出預設的大小。默認狀況下，oplog大小會佔用64位實例5%的可用磁盤空間

在MongoDB複製過程當中，主節點應用業務操做修改到數據庫中，而後記錄這些操做到oplog中，從節點複製這些oplog，而後應用這些修改。這些操做是異步的。若是從節點的操做已經被主節點落下很遠，oplog在從節點還沒執行完，oplog可能已經輪滾一圈了，從節點跟不上同步，複製就會停下，從節點須要從節點須要從新作完整的同步，爲了不這種狀況，儘可能保證主節點的oplog足夠大，可以存放至關長時間的操做記錄。

能夠調用db.runCommand命令來更改oplog的大小

1 這裏我是在從節點上進行的操做，最後將該節點改成主節點便可

  首先查看當前日誌的大小，這裏顯示爲990M

2 關掉該節點，先將它從複製集中移除，讓它變成一個單實例，而後纔好進行操做

3 對該節點的配置文件進行更改

4 修改這個節點的端口號，接着註釋掉複製集模塊

5 文件更改完成後就能夠啓動該實例了

6 首先將該實例的日誌文件進行完整性的備份

7 接着進入該實例的local數據下刪除原有的oplog

8 接着從新建立一份oplog，大小由本身自行定義

9 再次關閉該節點，由於咱們仍是要把這個實例加到複製集當中

10 再次對主配置文件進行配置，將端口改成原來的27018，同時開啓複製集模塊，最後寫上oplog的大小

11 文件配置完成後再次啓動該實例

12 進入到這個實例中能夠看到它已經被添加到複製集當中，角色爲從，oplog大小爲2048M

 

（4）部署認證複製

下面演示瞭如何部署帶用戶身份認證的MongoDB複製集

1 在活躍節點中建立root用戶，密碼爲123

2 在四個實例的配置文件中分別開啓密碼認證模塊，認證類型爲文件認證，而且寫上密碼文件的路徑，文件配置玩成後重啓四個實例

3 依照配置文件裏指定的路徑分別建立四個密碼文件，權限設爲600

4 在沒有輸入驗證的狀況下查看下數據庫信息和複製集的狀態，能夠看到是不會顯示咱們想要的信息的

5 在admin數據庫下輸入驗證就能夠進行查看

©著做權歸做者全部：來自51CTO博客做者BK白小白的原創做品，如需轉載，請註明出處，不然將追究法律責任

轉：http://blog.51cto.com/13706760/2175709