MongoDB Cluster Form Inquiry-one master one from one arbitration.

Master node (primary) with slave node (secondary) and quorum node (arbiter)
A three-member replica set with two members that store data has:
a master node.
One from the node. The slave node can become the primary node in the election.
A quorum node quorum node only votes in the election.

Because the quorum node does not save a copy of the data, this deployment provides only a complete copy of the data (secondary). The quorum node requires less resources and sacrifices more limited redundancy and fault tolerance.

However, with the master node, the deployment of the slave node and the quorum and the single is ensured that the replica set remains available if the primary server or slave server is unavailable.

If the primary server is unavailable, the replica set selects the slave node server as the primary server.

I was deployed through the trove component of OpenStack a cluster form of a master two from a replica set.

Test by stopping one of the nodes from the node, moving out of the cluster, and then turning him into a quorum node, as follows:

Https://docs.mongodb.com/v3.2/tutorial/convert-secondary-into-arbiter/index.html

The main point is that, since the trove created by cluster is enabled for authentication, it is necessary to keyfile at boot time to complete communication between the quorum node and the master-slave node.

Command:

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": +,    "localtime": Isodate ("2017-10-24t09:16:11.858z"),    "maxwireversion":4,    "minwireversion":0,    "OK":1}kill off the MongoDB process on the master node 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": +,    "localtime": Isodate ("2017-10-24t09:16:49.220z"),    "maxwireversion":4,    "minwireversion":0,    "OK":1,    "$gleStats" : {        "Lastoptime": Timestamp (0,0),        "Electionid": ObjectId ("7fffffff0000000000000006")    }}

Summarize:

1. If the primary node is down, the slave node will not be promoted to the primary node when we deploy it only in a master-one way.

(1): When restarting the master node, there are two possibilities. 1. The master node becomes the slave node, and the node is elected as the new master node. 2. The master-slave node does not change (presumably this is due to)

2. When a primary one is added to a quorum node,

(1): Master node down, from the node to promote the primary node.

(2): After the node restarts, it becomes the slave node of the current master node.

MongoDB Cluster Form Inquiry-one master one from one arbitration.