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")