Mongodb集群形式探究-一主一从一仲裁。
主节点(primary)与从节点(secondary)和仲裁节点(arbiter)
具有存储数据的两个成员的三个成员副本集具有:
●一个主节点。
●一个从节点。 从节点可以在选举中成为主节点。
●一个仲裁节点 仲裁节点只在选举中投票。
由于仲裁节点不保存数据副本,因此这种部署只提供一个完整的数据副本(secondary)。 仲裁节点需要更少的资源,牺牲更多有限的冗余和容错能力。
但是,使用主节点,从节点和仲裁及诶单的部署可确保如果主服务器或从服务器不可用,副本集仍将保持可用。
如果主服务器不可用,则副本集将选择从节点服务器为主服务器。
我是通过openstack的trove组件部署出来了一个一主两从组成的一个副本集的集群形式。
通过将其中一个从节点停掉,移出集群,然后将他变为仲裁节点的方式进行测试的,具体方法可以参照:
https://docs.mongodb.com/v3.2/tutorial/convert-secondary-into-arbiter/index.html
需要主要的是,由于trove创建的cluster开启了身份认证,所以在启动的时候需要keyfile来完成仲裁节点与主从节点之间的通信。
命令:
mongod --port 27017 --dbpath /data --replSet rs1 --config /etc/mongod.conf
rs1:SECONDARY> db.isMaster() { "hosts" : [ "192.168.111.173:27017", "192.168.111.174:27017" ], "arbiters" : [ "192.168.111.172:27017" ], "setName" : "rs1", "setVersion" : 8, "ismaster" : false, "secondary" : true, "primary" : "192.168.111.173:27017", "me" : "192.168.111.174:27017", "maxBsonObjectSize" : 16777216, "maxMessageSizeBytes" : 48000000, "maxWriteBatchSize" : 1000, "localTime" : ISODate("2017-10-24T09:16:11.858Z"), "maxWireVersion" : 4, "minWireVersion" : 0, "ok" : 1 } kill掉主节点上的mongodb进程 rs1:SECONDARY> db.isMaster() { "hosts" : [ "192.168.111.173:27017", "192.168.111.174:27017" ], "arbiters" : [ "192.168.111.172:27017" ], "setName" : "rs1", "setVersion" : 8, "ismaster" : true, "secondary" : false, "primary" : "192.168.111.174:27017", "me" : "192.168.111.174:27017", "electionId" : ObjectId("7fffffff0000000000000006"), "maxBsonObjectSize" : 16777216, "maxMessageSizeBytes" : 48000000, "maxWriteBatchSize" : 1000, "localTime" : ISODate("2017-10-24T09:16:49.220Z"), "maxWireVersion" : 4, "minWireVersion" : 0, "ok" : 1, "$gleStats" : { "lastOpTime" : Timestamp(0, 0), "electionId" : ObjectId("7fffffff0000000000000006") } }
总结:
1.当我们只使用一主一从的方式进行部署的时候,如果主节点down机,从节点不会提升为主节点。
(1):当重启主节点的时候,会发生两种可能性。1.主节点变为从节点,从节点选举为新的主节点。2.主从节点不变(推测这是由于)
2.当在一主一从中加入一个仲裁节点后,
(1):主节点down机,从节点提升为主节点。
(2):从节点重启之后会变为当前主节点的从节点。