MongoDB复制集的配置（基于Window ）

MongoDB 复制

MongoDB复制是将数据同步在多个服务器的过程。复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并可以保证数据的安全性。复制还允许您从硬件故障和服务中断中恢复数据。

为什么使用复制集？1、保障数据的安全性；2、数据高可用性 (24*7)；3、灾难恢复；4、无需停机维护（如备份，重建索引，压缩）；5、分布式读取数据

复制集原理

mongodb的复制至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。mongodb各个节点常见的搭配方式为：一主一从、一主多从。主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。

从节点类型：

副本节点：负责同步主节点的数据操作日志更新本地数据库，从而保证副本节点的数据和主节点上的数据的一致性；副本节点的从某种意义上来讲有点像赛跑，永远在追赶主节点的数据操作；

仲裁节点：不负责保存具体的数据，只是在副本集进行主节点选举时提供自己的一个选票而已。

Secondary-Only：和副本节点一样保存了主节点的数据副本，但是在任何情况下都成为不了Primary主节点；

Hidden：这种类型的节点对于客户端程序是不可见的，同样不能成为Primary主节点，但是可以参与投票；

Delayed：这种类型的节点可以通过人为的设置，可以指定一个时间来延迟从主节点同步数据，Delayed成员主要用于从一些误操作中恢复旧数据，并且肯定不能成为主节点而且是Hidden的；

复制集配置

本次复制集配置使用一个mongodb数据库，使用了三个节点，一个主节点（端口27000）、一个从节点（端口27001）、一个仲裁节点（端口27002）。mongodb的位置在“D:\MongoDB\Service1”下，在bin同级目录简历一个data目录、config目录和log目录，分别放置数据库数据、数据库实例配置信息和数据库日志。下面是data和config目录的截图，下面有三个分目录，分别存放每个节点的数据。

下面是主节点配置文件信息

dbpath=D:\MongoDB\Service1\data\rs1
logpath=D:\MongoDB\Service1\log\rs1.log
journal=true
port=27000
replSet=rs
logappend=true

从节点配置信息

dbpath=D:\MongoDB\Service1\data\rs2
logpath=D:\MongoDB\Service1\log\rs2.log
journal=true
port=27001
replSet=rs
logappend=true

仲裁节点配置信息

dbpath=D:\MongoDB\Service1\data\rs3
logpath=D:\MongoDB\Service1\log\rs3.log
journal=true
port=27002
replSet=rs
logappend=true

以上三个节点的复制集名字统一为rs。

然后在window命令提示符窗口进入mongodb数据库所在根目录的bin目录。本次演示的数据库目录是“D:\MongoDB\Service1\bin”。

然后使用以下命令分别启动mongo数据库服务。

//主节点实例服务启动命令
mongod --config D:\MongoDB\Service1\config\rs1\mongod.cfg

//从节点实例服务启动命令
mongod --config D:\MongoDB\Service1\config\rs2\mongod.cfg

//仲裁节点实例服务启动命令
mongod --config D:\MongoDB\Service1\config\rs3\mongod.cfg

成功启动的截图（注意启动后不要关闭命令窗口）。

三个节点全部启动后选择主节点，进入mongodb数据库命令界面（我这里使用studio 3T的图形界面软件）。使用初始化命令

rs.initiate()

成功的结果是（ok项是1，失败是0）。从节点和仲裁节点的“me”可以推断出来是ip加上端口号。注意此时不要初始化从节点和仲裁节点，不然后面主节点添加从节点的时候会报错。

然后初始化配置

rs.conf()

成功的结果是

最后向主节点添加从节点和仲裁节点

rs.add("localhost:27001")

rs.addArb("localhost:27002")

最后查看主节点状态

rs.status()

//本次演示主节点配置
{ 
    "set" : "rs", 
    "date" : ISODate("2018-08-25T08:24:41.554+0000"), 
    "myState" : 1.0, 
    "term" : NumberLong(1), 
    "syncingTo" : "", 
    "syncSourceHost" : "", 
    "syncSourceId" : -1.0, 
    "heartbeatIntervalMillis" : NumberLong(2000), 
    "optimes" : {
        "lastCommittedOpTime" : {
            "ts" : Timestamp(1535185471, 1), 
            "t" : NumberLong(1)
        }, 
        "readConcernMajorityOpTime" : {
            "ts" : Timestamp(1535185471, 1), 
            "t" : NumberLong(1)
        }, 
        "appliedOpTime" : {
            "ts" : Timestamp(1535185471, 1), 
            "t" : NumberLong(1)
        }, 
        "durableOpTime" : {
            "ts" : Timestamp(1535185471, 1), 
            "t" : NumberLong(1)
        }
    }, 
    "lastStableCheckpointTimestamp" : Timestamp(1535185441, 1), 
    "members" : [
        {
            "_id" : 0.0, 
            "name" : "localhost:27000", 
            "health" : 1.0, 
            "state" : 1.0, 
            "stateStr" : "PRIMARY", 
            "uptime" : 786.0, 
            "optime" : {
                "ts" : Timestamp(1535185471, 1), 
                "t" : NumberLong(1)
            }, 
            "optimeDate" : ISODate("2018-08-25T08:24:31.000+0000"), 
            "syncingTo" : "", 
            "syncSourceHost" : "", 
            "syncSourceId" : -1.0, 
            "infoMessage" : "", 
            "electionTime" : Timestamp(1535184719, 2), 
            "electionDate" : ISODate("2018-08-25T08:11:59.000+0000"), 
            "configVersion" : 5.0, 
            "self" : true, 
            "lastHeartbeatMessage" : ""
        }, 
        {
            "_id" : 1.0, 
            "name" : "localhost:27001", 
            "health" : 1.0, 
            "state" : 2.0, 
            "stateStr" : "SECONDARY", 
            "uptime" : 411.0, 
            "optime" : {
                "ts" : Timestamp(1535185471, 1), 
                "t" : NumberLong(1)
            }, 
            "optimeDurable" : {
                "ts" : Timestamp(1535185471, 1), 
                "t" : NumberLong(1)
            }, 
            "optimeDate" : ISODate("2018-08-25T08:24:31.000+0000"), 
            "optimeDurableDate" : ISODate("2018-08-25T08:24:31.000+0000"), 
            "lastHeartbeat" : ISODate("2018-08-25T08:24:40.962+0000"), 
            "lastHeartbeatRecv" : ISODate("2018-08-25T08:24:40.548+0000"), 
            "pingMs" : NumberLong(0), 
            "lastHeartbeatMessage" : "", 
            "syncingTo" : "localhost:27000", 
            "syncSourceHost" : "localhost:27000", 
            "syncSourceId" : 0.0, 
            "infoMessage" : "", 
            "configVersion" : 5.0
        }, 
        {
            "_id" : 2.0, 
            "name" : "localhost:27002", 
            "health" : 1.0, 
            "state" : 7.0, 
            "stateStr" : "ARBITER", 
            "uptime" : 21.0, 
            "lastHeartbeat" : ISODate("2018-08-25T08:24:39.782+0000"), 
            "lastHeartbeatRecv" : ISODate("2018-08-25T08:24:41.044+0000"), 
            "pingMs" : NumberLong(0), 
            "lastHeartbeatMessage" : "", 
            "syncingTo" : "", 
            "syncSourceHost" : "", 
            "syncSourceId" : -1.0, 
            "infoMessage" : "", 
            "configVersion" : 5.0
        }
    ], 
    "ok" : 1.0, 
    "operationTime" : Timestamp(1535185471, 1), 
    "$clusterTime" : {
        "clusterTime" : Timestamp(1535185471, 1), 
        "signature" : {
            "hash" : BinData(0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA="), 
            "keyId" : NumberLong(0)
        }
    }
}

注意members项里面的成员是不是你说添加的个数。并且每个节点的“stateStr”分别是“PRIMARY”、“SECONDARY”、“ARBITER”。这时候登陆从节点或者仲裁节点（不需要初始化和初始化配置）。查看节点状态，和主节点相同的配置会输出出来。

至此，本mongodb数据库的复制集配置完成。

复制集验证

本次复制集配置案例可以验证一下，及主节点复制数据的读写操作，从节点只负责读取。仲裁节点不负责数据的存储。

验证方法，想主节点插入一个集合，观察从节点和仲裁节点是否存在想主节点插入的集合。在主节点数据库命令窗口执行以下命令

use test
db.createCollection("testCollection")

下面是数据库树图截图（基于studio 3T）：

这时候观察主节点（27000）和从节点（27001）都会增加一个新的数据库test和新的集合testCollection。

 

验证结束，验证成功。配置复制集成功。