MongoDB中復制選舉的原理是什么

這期內容當中小編將會給大家帶來有關MongoDB中復制選舉的原理是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

MongoDB復制集的選舉原理

MongoDB復制的原理

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

MongoDB選舉的原理

MongoDB的節點分為三種類型，分別為標準節點（host）、被動節點（passive）和仲裁節點（arbiter）

• 只有標準節點才有可能被選舉為活躍節點（主節點），擁有選舉權。被動節點有完整副本，不可能成為活躍節點，具有選舉權。仲裁節點不復制數據，不可能成為活躍節點，只有選舉權。說白了就是只有標準節點才有可能被選舉為主節點，即使在一個復制集中說有的標準節點都宕機，被動節點和仲裁節點也不會成為主節點。后續有示例演示驗證。

• 標準節點與被動節點的區別：priority值高者是標準節點，低者則為被動節點

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

MongoDB復制集節點間選舉所示

前文鏈接
Yum安裝MongoDB及數據庫管理
配置MongoDB復制集

示例驗證復制集選舉原理

創建4個實例

創建新實例的path文件和dbpath的文件目錄，并為日志文件設置權限

mkdir -p /data/mongodb/logs
//  path目錄，因為在安裝完成之后就會有一個實例，所以這里我們只需要創建三個實例即可
mkdir -p /data/mongodb/mongo{2,3,4}           //創建dbpath目錄
touch /data/mongodb/logs/mongod{2,3,4}.log    //創建日志文件
chmod 777 /data/mongodb/logs/*.log            //為日志文件賦予權限

修改配置文件（/etc/mongod.conf）

path:
dbPath:
  port:
  bindIp:
replication:
  replSetName:      //修改配置文件中這五個項目的值

關閉防火墻及selinux防火墻

systemctl disable firewalld.service
systemctl stop firewalld.service
setenforce 0

啟動實例

mongod -f /etc/mongod.conf

配置復制集

創建有四個節點組成的復制集，創建時設置優先級

本次復制集由四個節點組成，分別包括兩個標準節點，一個被動節點，一個仲裁節點。

mongo //=進入數據庫
chen={"_id":"chenrs","members":[{"_id":0,"host":"172.16.10.29:27017","priority":100},{"_id":1,"host":"172.16.10.29:27018","priority":100},{"_id":2,"host":"172.16.10.29:27019","priority":0},{"_id":3,"host":"172.16.10.29:27020","arbiterOnly":true}]}

初始化復制集

rs.initiate(chen)

查看各節點的的身份

rs.isMaster()

查看oplpog日志

此時對數據庫進行一些增刪改查的操作，注意在oplog日志中不會記錄查詢的語句，只會記錄對數據庫進行更改的語句

use stady                                      //使用stady庫
db.abc.insert({"id":1,"name":"zhangsan"})      //向表abc中寫入一條數據
db.abc.insert({"id":2,"name":"lisi"})          //再次插入一條數據
db.abc.find()                                  //查看表中內容
db.abc.update({"id":2},{$set:{"name":"jack"}}) //修改表數據
db.abc.remove({"id":1}                         //刪除表數據

查看oplog中內容

use local
show collections    //可以看到其中有一個oplog.rs文件
db.oplog.rs.find()  
//由于內容過多，在這里就不展示，查看之后就會發現，沒有記錄查詢的記錄，只有記錄對數據庫做更改的操作

模擬主節點故障

關閉主節點

kill -9 + 進程號                         //關閉主節點
mongod -f /etc/mongod4.conf --shutdown   //關閉主節點
mongo --port 27018
chenrs:PRIMARY> rs.status()      //此時該節點已經成為主節點
{
    "set" : "chenrs",
    "date" : ISODate("2018-07-16T05:30:04.152Z"),
    "myState" : 1,
        ···省略部分內容
    "members" : [
            "_id" : 0,
            "name" : "172.16.10.29:27017",
            "health" : 0,                 //健康值為0，處于非活躍狀態
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
        ···省略部分內容
            "_id" : 1,
            "name" : "172.16.10.29:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",    //此時1為主節點
        ···省略部分內容   
            "_id" : 2,
            "name" : "172.16.10.29:27019",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
        ···省略部分內容
            "_id" : 3,
            "name" : "172.16.10.29:27020",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
        ···省略部分內容
        ]

模擬另外一個主節點故障

mongod -f /etc/mongod2.conf --shutdown
mongo --port 27019
chenrs:SECONDARY> rs.status()     //仍處于secondary狀態
{
    "set" : "chenrs",
    "date" : ISODate("2018-07-16T05:40:09.740Z"),
    "members" : [
        {
            "_id" : 0,
            "name" : "172.16.10.29:27017",
            "health" : 0,
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
            ···省略部分內容
            "_id" : 1,
            "name" : "172.16.10.29:27018",
            "health" : 0,
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
        ···省略部分內容
            "_id" : 2,
            "name" : "172.16.10.29:27019",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",          //即使兩個標準節點都處于宕機狀態，被動節點和仲裁節點也沒有成為主節點
        ···省略部分內容
            "_id" : 3,
            "name" : "172.16.10.29:27020",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
        ]
        ···省略部分內容

MongoDB復制集管理

配置允許在從節點讀取數據

默認MongoDB復制集的從節點是不能讀取數據的，但是可以使用密令來允許能夠在從節點讀取數據

rs.slaveOk()    //允許從節點能夠讀取數據

查看復制集狀態信息

rs.help 
rs.printReplicationInfo()        //查看oplog日志文件的大小及時間范圍
rs.printSlaveReplicationInfo()   //查詢節點及節點復制的時間

調整oplog日志文件大小

如果節點屬于復制集成員，此時你想要修改oplog的大小是不被允許的，所以要將節點移出復制集想要修改日志文件的默認大小。此時要做的是首先要關閉節點的服務，然后退出復制集

關閉節點服務（屬于離線升級）

use admin            //在復制集的從節點上做
db.shutdownServer()  //關閉服務，此時再想登陸該節點則會失敗

節點退出復制集

注銷掉replication的值和修改port值，將其作為單實例啟動

vim /etc/mongod2.conf
#replication:
#  replSetName: chenrs
port： 27028
mongod -f /etc/mongod2.conf   //啟動實例，此時該實例不屬于復制集

完全備份oplog日志

mongodump --port 27028 --db local --collection 'oplog.rs'   //在linux界面操作

刪除節點中oplog文件

> use local
> db.oplog.rs.drop()

重建oplog日志

db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } )

再次關閉節點服務

use admin
db.shutdownServer()

將節點加入到復制集

回調參數，同時要加一個參數指定日志文件大小

vim /etc/mongod2.conf
replication:
  replSetName: chenrs
  oplogSizeMB: 2048    //單位為兆
mongod -f /etc/mongod2.conf      //啟動實例
mongo -port 27018                //進入實例

查看oplog大小

rs.printReplicationInfo()

對于日志文件大小的更改，只對該節點生效，其他節點仍然是默認值

部署認證復制

創建管理用戶

use admin
db.createUser({"user":"root","pwd":"123123","roles":["root"]})

配置密鑰驗證

為了使其他的節點還能夠和主節點進行同步，創建密鑰文件使其他節點能夠同步

• 創建驗證文件

  # cd /usr/bin/
  # echo "chenrs key"> chenrskey1
  # echo "chenrs key"> chenrskey2
  # echo "chenrs key"> chenrskey3
  # echo "chenrs key"> chenrskey4    //密鑰內容自定義，但是要保證內容的一致性
  # chmod 600 chenrskey{1..4}        //設置文件權限，不設置在接下來的啟動中會報錯

• 修改配置文件，開啟mongodb的安全驗證功能（四個配置文件都要修改，注意內容差異）

  vim /etc/mongod.conf
  security:
  keyFile: /usr/bin/chenrskey1     //每個節點的驗證文件不同，要根據不同的節點修改
  clusterAuthMode: keyFile        //認證類型，密鑰文件認證

  

• 重啟服務

  mongod -f /etc/mongod.conf --shutdown
  mongod -f /etc/mongod.conf              /其他幾臺的重啟方式都相同，重復操作即可

  身份驗證登陸（先驗證主，再驗證從）

  當你直接使用登陸命令登陸系統時，使用show dbs 是不能夠查看數據的，此時就需要使用身份驗證

  mongo --port 27018
  use admin
  db.auth("root","123123")

  

上述就是小編為大家分享的MongoDB中復制選舉的原理是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。