Mongo服务器集群配置学习二——副本集
Mongo服务器集群配置学习二——副本集
所谓副本集就是有自动故障恢复功能的主从集群，学习一中的主从复制和副本集最大的区别就是：副本集没有固定的“主节点”，整个集群结构会动态选举出一个“主节点”，当其坏掉，则会动态变更到其他节点，而主从复制又要人为的去切换。副本集的节点称为活跃节点和备份节点。
想配置如下图的副本集集群，很简单一个活跃节点，一个备份节点，当然由于活跃节点是动态推选出来的，不能指定，配置完之后可以看看哪台是活跃点，我希望是A。
对于副本集，需要指定一个副本集的名称，本例为replicademo，用来确定该名称的副本集集群都有哪些主机
下面对A和B进行配置，配置文件如下
A：
dbpath=D:\mongodb\test\replicaSet\A\Data
bind_ip=127.0.0.1
port=11111
replSet=replicademo/127.0.0.1:22222
B：
dbpath=D:\mongodb\test\replicaSet\B\Data
bind_ip=127.0.0.1
port=22222
replSet=replicademo/127.0.0.1:11111
replSet参数为“副本集名称”/主机地址：端口号，注意“/”必须要有
然后分别启动A和B
随便在其中一台节点上进行副本集初始化配置，首先切换到admin库，并执行下面脚本
db.runCommand({"replSetInitiate":
{
"_id":'replicademo',
"members":[
{
"_id":1,
"host":"127.0.0.1:11111"
},
{
"_id":2,
"host":"127.0.0.1:22222"
}
]
}
})
脚本中各字段代表的含义是
1. “_id” ： “replicademo”， 这个键指明了副本集的名称
2. “members” ：[...]， 这个键指明服务器列表，我们以后还可以往副本集中加入服务器
3. “_id” : N， 内嵌文档的键，用于唯一标示副本集中的某一台服务器
4. “host”：host address， 指明服务器的主机和端口号
这样我们再来看A和B两台的shell
A:
B：
由此看来A这台是活跃节点，在活跃节点上进行状态查询
rs.status()
展示如下图信息
可以清楚的看到副本集集群中各节点的状态。
状态查询之所以要在动态节点上进行，是因为备份节点默认不支持查询操作，可以做下面的实验。在A上插入数据，并可以在A查到
replicademo:PRIMARY> use person
switched to db person
replicademo:PRIMARY> db.person.info.insert({name:"tom"})
replicademo:PRIMARY> db.person.info.find()
{ "_id" : ObjectId("516a629b91dee924cc38e01a"), "name" : "tom" }
在备份节点上进行这条数据的查询，很显然报错了。
默认情况下SECONDARY不能读写，如果想进行读取操作，可以执行rs.slaveOk()，就可以从SECONDARY读取了。
replSet里只能有一个Primary库，只能从Primary写数据，不能向SECONDARY写数据
replicademo:SECONDARY> use person
switched to db person
replicademo:SECONDARY> db.person.info.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }
副本集故障切换
当A不能工作了，会发生什么情况，我先把A关掉，A和B的shell也关闭，再重新启动B的shell。会发现B并没有变成活跃节点，仍然是备份节点。
原因如下：当SECONDARY Down掉,剩下一个PRIMARY,此时副本集运行不会出问题,因为不用选择PRIMARY节点，当PRIMARY Down掉,此时副本集只剩下一个SECONDARY,它只有1票,不超过总节点数的半数,它不会选举自己为PRIMARY节点。
所以副本集中只有2台备份服务器是不合理的。
添加删除节点
上面的情况已经看到只有2个备份节点是不合理的，解决方案是要不就再加一台备份节点，使得投票能正常选出活跃节点，另一种方法是增加仲裁节点。
先说下副本集中有3中节点：
standard：常规节点，也就是我上个例子中用到的A和B都是常规节点，它既存储完整的数据副本又参加投票，可以成为活跃节点
passive：副本节点，它虽存储完整的数据副本又参加投票，但是不可以成为活跃节点
arbiter：仲裁节点，只参与投票，不接受数据的复制，不可以成为活跃节点
1.副本集replicademo中添加一个常规节点
启动另一台节点服务器C
dbpath=D:\mongodb\test\replicaSet\C\Data
bind_ip=127.0.0.1
port=33333
replSet=replicademo/127.0.0.1:11111,127.0.0.1:22222
在活跃节点上执行rs.add("127.0.0.1:33333")
执行完成之后查询配置如下，可以看到C已经加入到副本集。
如果要删除某一个节点可以执行rs.remove("主机名:端口号")
执行之后查看配置，发现节点已经被删除
2.副本集replicademo中添加一个仲裁节点
在活跃节点上执行rs.add("127.0.0.1:33333",true)
此时在查询状态，如下图，节点C的stateStr="ARBITER",已经变为仲裁节点。
所谓副本集就是有自动故障恢复功能的主从集群，学习一中的主从复制和副本集最大的区别就是：副本集没有固定的“主节点”，整个集群结构会动态选举出一个“主节点”，当其坏掉，则会动态变更到其他节点，而主从复制又要人为的去切换。副本集的节点称为活跃节点和备份节点。
想配置如下图的副本集集群，很简单一个活跃节点，一个备份节点，当然由于活跃节点是动态推选出来的，不能指定，配置完之后可以看看哪台是活跃点，我希望是A。
对于副本集，需要指定一个副本集的名称，本例为replicademo，用来确定该名称的副本集集群都有哪些主机
下面对A和B进行配置，配置文件如下
A：
dbpath=D:\mongodb\test\replicaSet\A\Data
bind_ip=127.0.0.1
port=11111
replSet=replicademo/127.0.0.1:22222
B：
dbpath=D:\mongodb\test\replicaSet\B\Data
bind_ip=127.0.0.1
port=22222
replSet=replicademo/127.0.0.1:11111
replSet参数为“副本集名称”/主机地址：端口号，注意“/”必须要有
然后分别启动A和B
随便在其中一台节点上进行副本集初始化配置，首先切换到admin库，并执行下面脚本
db.runCommand({"replSetInitiate":
{
"_id":'replicademo',
"members":[
{
"_id":1,
"host":"127.0.0.1:11111"
},
{
"_id":2,
"host":"127.0.0.1:22222"
}
]
}
})
脚本中各字段代表的含义是
1. “_id” ： “replicademo”， 这个键指明了副本集的名称
2. “members” ：[...]， 这个键指明服务器列表，我们以后还可以往副本集中加入服务器
3. “_id” : N， 内嵌文档的键，用于唯一标示副本集中的某一台服务器
4. “host”：host address， 指明服务器的主机和端口号
这样我们再来看A和B两台的shell
A:
B：
由此看来A这台是活跃节点，在活跃节点上进行状态查询
rs.status()
展示如下图信息
可以清楚的看到副本集集群中各节点的状态。
状态查询之所以要在动态节点上进行，是因为备份节点默认不支持查询操作，可以做下面的实验。在A上插入数据，并可以在A查到
replicademo:PRIMARY> use person
switched to db person
replicademo:PRIMARY> db.person.info.insert({name:"tom"})
replicademo:PRIMARY> db.person.info.find()
{ "_id" : ObjectId("516a629b91dee924cc38e01a"), "name" : "tom" }
在备份节点上进行这条数据的查询，很显然报错了。
默认情况下SECONDARY不能读写，如果想进行读取操作，可以执行rs.slaveOk()，就可以从SECONDARY读取了。
replSet里只能有一个Primary库，只能从Primary写数据，不能向SECONDARY写数据
replicademo:SECONDARY> use person
switched to db person
replicademo:SECONDARY> db.person.info.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }
副本集故障切换
当A不能工作了，会发生什么情况，我先把A关掉，A和B的shell也关闭，再重新启动B的shell。会发现B并没有变成活跃节点，仍然是备份节点。
原因如下：当SECONDARY Down掉,剩下一个PRIMARY,此时副本集运行不会出问题,因为不用选择PRIMARY节点，当PRIMARY Down掉,此时副本集只剩下一个SECONDARY,它只有1票,不超过总节点数的半数,它不会选举自己为PRIMARY节点。
所以副本集中只有2台备份服务器是不合理的。
添加删除节点
上面的情况已经看到只有2个备份节点是不合理的，解决方案是要不就再加一台备份节点，使得投票能正常选出活跃节点，另一种方法是增加仲裁节点。
先说下副本集中有3中节点：
standard：常规节点，也就是我上个例子中用到的A和B都是常规节点，它既存储完整的数据副本又参加投票，可以成为活跃节点
passive：副本节点，它虽存储完整的数据副本又参加投票，但是不可以成为活跃节点
arbiter：仲裁节点，只参与投票，不接受数据的复制，不可以成为活跃节点
1.副本集replicademo中添加一个常规节点
启动另一台节点服务器C
dbpath=D:\mongodb\test\replicaSet\C\Data
bind_ip=127.0.0.1
port=33333
replSet=replicademo/127.0.0.1:11111,127.0.0.1:22222
在活跃节点上执行rs.add("127.0.0.1:33333")
执行完成之后查询配置如下，可以看到C已经加入到副本集。
如果要删除某一个节点可以执行rs.remove("主机名:端口号")
执行之后查看配置，发现节点已经被删除
2.副本集replicademo中添加一个仲裁节点
在活跃节点上执行rs.add("127.0.0.1:33333",true)
此时在查询状态，如下图，节点C的stateStr="ARBITER",已经变为仲裁节点。
