MongoDB復制選舉原理以及復制集的管理

MongoDB復制集的節點是通過選舉產生主節點的。

復制的原理：復制是基于操作日志oplog，相當于MySQL的二進制日志，只記錄發生改變的記錄。復制將主節點的oplog日志同步并應用到其他從節點的過程

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

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

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

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

下圖為MongoDB復制集節點間選舉的結構圖

下面我會通過幾個實驗來驗證復制集的選舉原理

一、 創建四個節點，端口分別為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數據庫下輸入驗證就可以進行查看