Mongo server cluster configuration learning secondary feature set

Mongo server cluster configuration learning secondary replica set the so-called replica set is a master-slave cluster with automatic fault recovery function. The biggest difference between master-slave replication and replica set in learning No. 1 is that the replica set does not have a fixed master node, the entire cluster structure will dynamically elect a master node. If it fails, it will be dynamically changed to other nodes, and master-slave replication will have to be manually switched.

Mongo server cluster configuration learning secondary replica set the so-called replica set is a master-slave cluster with automatic fault recovery function. The biggest difference between master-slave replication and replica set in learning No. 1 is that the replica set does not have a fixed master node, the entire cluster structure will dynamically elect a master node. If it fails, it will be dynamically changed to other nodes, and master-slave replication will have to be manually switched.

Mongo server cluster configuration learning 2-replica set

The replica set is a master-slave cluster with automatic fault recovery. The biggest difference between master-slave replication and replica set in learning No. 1 is that the replica set does not have a fixed "master node ", the entire cluster structure will dynamically elect a "master node". When it breaks down, it will be dynamically changed to other nodes, and master-slave replication will have to be manually switched. The node of the replica set is called an active node and a backup node.

To configure a replica Set cluster, you can easily create an active node and a backup node. Of course, because the active nodes are dynamically selected, they cannot be specified, after configuration, You can see which one is active. I hope it is.

For replica sets, You need to specify the name of a replica set. In this example, replicademo is used to determine which hosts are included in the replica Set cluster.
Configure A and B. The configuration file is as follows:
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
The replSet parameter is "Replica Set Name"/Host address: port number. Note that "/" must have
Then start A and B respectively
Initialize the replica set on any node. First, switch to the admin database and execute the following script.
Db. runCommand ({"replSetInitiate ":
{
"_ Id": 'replicademo ',
"Members ":[
{
"_ Id": 1,
"Host": "127.0.0.1: 11111"
},
{
"_ Id": 2,
"Host": "127.0.0.1: 22222"
}
]
}
})

The meaning of each field in the script is
1. "_ id": "replicademo". This key specifies the replica set name.
2. "members": [...]. This key specifies the server list. We can add servers to the replica set in the future.
3. "_ id": N, the key of the embedded document, used to uniquely identify a server in the replica set
4. "host": host address, indicating the host and port number of the server
In this case, let's look at the two shells A and B.
A:
B:
As A result, A is an active node and queries the status of the active node.
Rs. status ()
Display Information

You can clearly see the status of each node in the replica Set cluster.
Status query is performed on a dynamic node because the backup node does not support query by default. You can perform the following experiment. Insert data on A and check it in.
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 "}
When querying this data on the backup node, it is clear that an error is returned.
By default, SECONDARY cannot read or write data. If you want to perform a read operation, you can execute rs. slaveOk () to read data from SECONDARY.
There can only be one Primary database in the replSet, and data can only be written from Primary. data cannot be written to SECONDARY.
Replicademo: SECONDARY> use person
Switched to db person
Replicademo: SECONDARY> db.person.info. find ()
Error: {"$ err": "not master and slaveOk = false", "code": 13435}
Replica set failover
When A cannot work, what will happen? I first turn off A, and the shell of A and B, and then restart B's shell. B is still a backup node.
The reason is as follows: when SECONDARY is Down, there is one PRIMARY left. At this time, the replica set runs normally, because you do not need to select the PRIMARY node. When PRIMARY is Down, only one SECONDARY is 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.
Therefore, it is unreasonable to have only two backup servers in the replica set.
Add or delete a node
The above situation has seen that it is unreasonable to have only two backup nodes. The solution is to add another backup node, so that the active nodes can be elected properly by voting, another method is to add arbitration nodes.
First, there are three nodes in the replica set:
Standard
Passive: A copy node. Although it stores complete data copies and participates in voting, it cannot become an active node.
Arbiter: Arbitration node. It only participates in voting and does not accept data replication. It cannot be an active node.
1. Add a regular node to the replica set replicademo
Start another node server 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
Execute rs. add ("127.0.0.1: 33333") on the active node ")
After the execution is complete, the query configuration is as follows. You can see that C has been added to the replica set.

To delete a node, execute rs. remove ("Host Name: Port Number ")
Check the configuration and find that the node has been deleted.

2. Add an arbitration node to the replica set replicademo

Execute rs. add ("127.0.0.1: 33333", true) on the active node)
At this time, the query status, such as stateStr = "ARBITER" of node C, has changed to the arbitration node.