主节点（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" : ,
"ismaster" : false,
"secondary" : true,
"primary" : "192.168.111.173:27017",
"me" : "192.168.111.174:27017",
"maxBsonObjectSize" : ,
"maxMessageSizeBytes" : ,
"maxWriteBatchSize" : ,
"localTime" : ISODate("2017-10-24T09:16:11.858Z"),
"maxWireVersion" : ,
"minWireVersion" : ,
"ok" :
}

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" : ,
"ismaster" : true,
"secondary" : false,
"primary" : "192.168.111.174:27017",
"me" : "192.168.111.174:27017",
"electionId" : ObjectId("7fffffff0000000000000006"),
"maxBsonObjectSize" : ,
"maxMessageSizeBytes" : ,
"maxWriteBatchSize" : ,
"localTime" : ISODate("2017-10-24T09:16:49.220Z"),
"maxWireVersion" : ,
"minWireVersion" : ,
"ok" : ,
"$gleStats" : {
"lastOpTime" : Timestamp(, ),
"electionId" : ObjectId("7fffffff0000000000000006")
}
}

总结：

1.当我们只使用一主一从的方式进行部署的时候，如果主节点down机，从节点不会提升为主节点。

（1）：当重启主节点的时候，会发生两种可能性。1.主节点变为从节点，从节点选举为新的主节点。2.主从节点不变（推测这是由于）

2.当在一主一从中加入一个仲裁节点后，

（1）：主节点down机，从节点提升为主节点。

（2）：从节点重启之后会变为当前主节点的从节点。