逻辑图

image.png

复制集中主要有三类节点：

Primary节点：主节点，写操作只能在主节点上进行，primary节点把操作记录在primary节点的oplog中，从节点从oplog中同步数据。

The primary is the only member in the replica set that receives write operations. MongoDB applies write operations on the primary and then records the operations on the primary’s oplog. Secondary members replicate this log and apply the operations to their data sets.

Secondary节点：从节点，从节点从主节点的oplog中同步数据。

A secondary maintains a copy of the primary’s data set. To replicate data, a secondary applies operations from the primary’s oplog to its own data set in an asynchronous process. A replica set can have one or more secondaries.

Arbiter节点：仲裁节点，仲裁节点不存储数据也不会成为主节点，它只在选举的时候投一票。当复制集成员为偶数时，最好加入一个仲裁节点，以提升复制集可用性。

An arbiter does not have a copy of data set and cannot become a primary. Replica sets may have arbiters to add a vote in elections for primary.

下面的操作是如何配置复制集

一个主节点，一个从节点，一个仲裁节点

2.1 配置mongod.conf

编辑mongodb的配置文件

sudo vim /etc/mongod.conf

在replication下添加（注意yml格式）

replication:
   replSetName: GridSum

该操作是开启复制集并为复制集设置名称为GridSum

在所有要同步的mongodb节点上都执行上面的配置，注意复制集的名称一定要一致，也就是主节点，从节点和仲裁节点都进行相同的配置。

2.2 在主节点上执行rs.initiate()

配置好复制集之后登录到有数据的节点，注意一定要在有数据的节点上配置，也就是主节点。

定义一个config配置,将需要同步的节点配置进来（注意引号和括号都是英文状态下的）

config={
    _id:"GridSum",
    members:[
        {_id:0,host:"10.203.40.114:27017"},
        {_id:1,host:"10.203.40.115:27017"},
        {_id:3,host:"10.203.40.116:27017",arbiterOnly:true}
    ]
}

上面的配置是将10.203.40.114:27017，10.203.40.115:27017，10.203.40.116:27017，添加到复制集，并指定116节点为仲裁节点。

定义好config之后执行

rs.initiate(config);

如果出现下面的结果说明配置成功

{ "ok" : 1 }

可以通过

rs.status();

查看复制集的状态可以看出哪个是主节点，哪个是从节点，那个是仲裁节点
下面是一个rs.status()的示例

{
    "set" : "GridSum",
    "date" : ISODate("2017-10-14T09:03:00.713Z"),
    "myState" : 7,
    "term" : NumberLong(4),
    "heartbeatIntervalMillis" : NumberLong(2000),
    "optimes" : {
        "lastCommittedOpTime" : {
            "ts" : Timestamp(1507971772, 1),
            "t" : NumberLong(4)
        },
        "appliedOpTime" : {
            "ts" : Timestamp(1507971772, 1),
            "t" : NumberLong(4)
        },
        "durableOpTime" : {
            "ts" : Timestamp(0, 0),
            "t" : NumberLong(-1)
        }
    },
    "members" : [
        {
            "_id" : 3,
            "name" : "10.203.40.114:27017",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
            "uptime" : 3981643,
            "configVersion" : 6,
            "self" : true
        },
        {
            "_id" : 4,
            "name" : "10.203.40.115:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 3901957,
            "optime" : {
                "ts" : Timestamp(1507971772, 1),
                "t" : NumberLong(4)
            },
            "optimeDurable" : {
                "ts" : Timestamp(1507971772, 1),
                "t" : NumberLong(4)
            },
            "optimeDate" : ISODate("2017-10-14T09:02:52Z"),
            "optimeDurableDate" : ISODate("2017-10-14T09:02:52Z"),
            "lastHeartbeat" : ISODate("2017-10-14T09:02:57.244Z"),
            "lastHeartbeatRecv" : ISODate("2017-10-14T09:03:00.618Z"),
            "pingMs" : NumberLong(0),
            "electionTime" : Timestamp(1505718572, 1),
            "electionDate" : ISODate("2017-09-18T07:09:32Z"),
            "configVersion" : 6
        },
        {
            "_id" : 5,
            "name" : "10.203.40.116:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 3901493,
            "optime" : {
                "ts" : Timestamp(1507971772, 1),
                "t" : NumberLong(4)
            },
            "optimeDurable" : {
                "ts" : Timestamp(1507971772, 1),
                "t" : NumberLong(4)
            },
            "optimeDate" : ISODate("2017-10-14T09:02:52Z"),
            "optimeDurableDate" : ISODate("2017-10-14T09:02:52Z"),
            "lastHeartbeat" : ISODate("2017-10-14T09:02:57.243Z"),
            "lastHeartbeatRecv" : ISODate("2017-10-14T09:03:00.483Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "10.203.40.115:27017",
            "configVersion" : 6
        }
    ],
    "ok" : 1
}

示例中members是节点列表，节点的stateStr表示节点的类型，上面示例中10.203.40.114是仲裁节点（ARBITER），10.203.40.115是主节点（PRIMARY），10.203.40.116是从节点（SECONDARY）。

2.3 动态修改节点

在主节点上可以动态添加，移除节点.

添加节点

rs.add('10.203.40.116:27017')

添加仲裁节点

rs.add('10.203.40.116:27017', true)

删除节点

rs.remove('10.203.40.116:27017') 

注意事项

如果rs.initiate(config)时如果出现

{
    "ok" : 0,
    "errmsg" : "'10.203.40.114:27017' has data already, cannot initiate set.",
    "code" : 110,
    "codeName" : "CannotInitializeNodeWithData"
}

网上大部分说法是在其他的mongodb上执行db.dropDatabase(),我试了还是不行。

解决方法：停掉其他mongdb服务器，然后把停掉的mongodb data目录里面的数据全部删除
再启动，然后重新配置就可以了。data目录可以在配置文件查找
通过第一步安装的mongodb配置文件在/etc/mongod.conf
配置文件中的storage.dbPath就是mongodb的data目录。

storage:
  dbPath: /var/lib/mongo

这里是data目录是/var/lib/mongo目录。

从节点是不能执行任何操作的，
如果要从从节点上能查询数据
在要查询的从节点上执行

rs.slaveOk();

就可以查询数据了

参看文献

https://docs.mongodb.com/manual/tutorial/deploy-replica-set/