2 standard nodes + 1 arbiter node to build MongoDB replication Sets
Create a directory [root @ localhost ~] # Mkdir-P/data/replset/R0 [root @ localhost ~] # Mkdir-P/data/replset/R1 [root @ localhost ~] # Mkdir-P/data/replset/R2 [root @ localhost ~] # Mkdir-P/data/replset/Key [root @ localhost ~] # Mkdir-P/data/replset/log
Create key [root @ localhost ~] # Echo "replset1 key">/data/replset/key/R0 [root @ localhost ~] # Echo "replset1 key">/data/replset/key/R1 [root @ localhost ~] # Echo "replset1 key">/data/replset/key/R2 [root @ localhost ~] # Chmod 600/data/replset/key/R * // 600 to prevent other programs from rewriting this key
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R0 -- replset replset1 -- Keyfile/data/replset/key/R0 -- Port 28010
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R1 -- replset replset1 -- Keyfile/data/replset/key/R1 -- Port 28011
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R2 -- replset replset1 -- Keyfile/data/replset/key/R2 -- Port 28012
Note: After the Keyfile/data/key/R0 is added, mongvue cannot be connected.
Use the following command to view logs)
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R0 -- replset replset1 -- Port 28010 -- directoryperdb
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R1 -- replset replset1 -- Port 28011 -- directoryperdb
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R2 -- replset replset1 -- Port 28012 -- directoryperdb
To run the program in the background, use the following:
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R0 -- replset replset1 -- Port 28010 -- logpath =/data/replset/log/r0.log -- logappend -- fork -- directoryperdb
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R1 -- replset replset1 -- Port 28011 -- logpath =/data/replset/log/r1.log -- logappend -- fork -- directoryperdb
/Apps/Mongo/bin/mongod -- dbpath =/data/replset/R2 -- replset replset1 -- Port 28012 -- logpath =/data/replset/log/r2.log -- logappend -- fork -- directoryperdb
Initialize the replica set:
/Apps/Mongo/bin/Mongo -- Port 28010config_replset1 = {_ ID: "replset1", members: [{_ ID: 0, host: "127.0.0.1: 28010", priority: 4}, {_ ID: 1, host: "127.0.0.1: 28011", Priority: 2}, {_ ID: 2, host: "127.0.0.1: 28012", arbiteronly: true}]} note that the arbiter arbitration node only votes and does not receive copied data!
Rs. Initiate (config_replset1 );
/Apps/Mongo/bin/Mongo -- Port 28010/apps/Mongo/bin/Mongo -- Port 28011/apps/Mongo/bin/Mongo -- Port 28012
// Write a data entry to primary
// Secondary cannot be written, but after slaveok is set, data may be read from secondaryBy default, secondary cannot read or write data. You must set the database. getmongo (). setslaveok (); only one primary database can be read from secondary in replset. data can only be written from primary and cannot be written to secondary.
// Neither arbiter can read or write data
Note that the arbiter arbitration node only votes and does not receive copied data !, Do not receive data from mydb written by primary!
From the arbiter node, we can see that arbiter only stores the configuration information of the replica set in local. system. replset, without oplog. RS, and arbiter does not receive the data of mydb written by primary! It indicates that arbiter "only plays a voting role and does not receive copied data "!
Look at Primary's local. Slaves and see that there is only one slave (not two). This slave is the secondary node. Here the arbiter node is not the primary slave,
This also indicates that arbiter "only plays a role in voting and does not receive copied data "!
Failover test:
CTRL + C ExitPrimary process, primary node 28010 is down,
Look at the originalSecondary (28011) node. After the arbiter node (28012) primary node 28010 is down, Arbiter will vote for secondary 28011, and secondary will become the new primary node.
Conclusion: 1: when the total number of votes in the replica set is an even number, the primary node may not be elected. mongod will prompt:
It is unreasonable for two standard nodes to form replication sets because they do not have the Failover capability!A: When secondary is down, there is a primary left. At this time, the replica set runs normally, because you do not need to select primary node B: When primary is down, there is only one secondary left in the replica set, it has only one vote and does not count more than half of the total number of nodes. It does not elect itself as a primary node! Note: three standard nodes can form replication sets. When the primary node is down, you can select another primary node. At this time, you need to repair the down node immediately, if the current primary node is down again, the next secondary node will not be able to select the primary node!
Feasible Solution: three standard nodes or two standard nodes + one arbiter Node
I personally feel that if there are only two servers, you can deploy a high-priority standard to one high-performance server, and then deploy another standard node + one arbiter node to another server, in this way, the primary node is on one server, the secondary node and the arbiter node are on the other server, so that no matter which node is broken, the replset can also serve
