MongoDB cluster--replica set

1. Structure and principle of replica set

The replica set consists of three nodes: the master node, the slave node, and the quorum node.
The master node is responsible for processing client requests, reading and writing data, and recording the Oplog of all operations on it;


The primary node is periodically polled from the node to get these operations, and then perform these operations on its own copy of the data, ensuring that the data from the node is consistent with the primary node. By default, external reads are not supported from the node, but can be set;
The mechanism of the replica set is that when the primary node fails, the remaining nodes elect a new master node to ensure that the system can function properly.


The quorum node does not copy data and participates in voting only. Because it has no access to the pressure, it is relatively idle and therefore not prone to malfunction. Because the replica set fails, the surviving node must be greater than half the total number of replica set nodes, or the primary node cannot be elected, or the master node is automatically demoted to the slave node, and the entire replica set becomes read-only. Therefore, adding a quorum node that is not prone to failure can increase the number of valid ballots and reduce the risk of the entire replica set being unavailable. There can be more than one quorum node.

2. Build a replica set
1) Start all node instances with the same replica set name
Example:
Mongod--port 40000--dbpath rs0\data\--logpath rs0\log\rs0.log--replset MySet
Mongod--port 40001--dbpath rs1\data\--logpath rs1\log\rs1.log--replset MySet
......
2) Initialization of the replica set at any node
Example:
MONGO jsj-1306-201:40000
>use Admin
> config={_id: "MySet", members:[
{_id:0,host: "jsj-1306-201:40000", "Priority": 2},
{_id:1,host: "jsj-1306-201:40001"},
{_id:2,host: "jsj-1306-201:40002", arbiteronly:true}
]}
>rs.initiate (config);
3) Check the replica set
>rs.conf ()
Or
>rs.status ()
4) Add node
To add a node, the primary node needs to be
Primary>>rs.add (Hostname:port)
5) Deletion of nodes
The node needs to be deleted at the primary node.
Primary>rs.remove (Hostname:port)
3. Test copy set
1) test data replication
First insert a record on the master node
myset:primary> Use test
Switched to DB test
Myset:primary> for (var i=1;i<=1000;i++) Db.table1.save ({id:i, "test1": "Testval1"}
);
Then connect a Slave node and read the data on that node:
myset:secondary> Use test
Switched to DB test
Myset:secondary> Db.table1.find (). Count ()
Data synchronization Success
2) test failover
At any one node, observe the replica set condition:
>rs.status ()
Then close the other node and then observe
>rs.status ()
As long as the remaining nodes exceed half of the total, the replica set can be automatically failed over:
If the primary node is closed, the replica set selects the new primary node, and if the slave node is closed, the master node remains running.
If the remaining node is less than or equal to half of the total number of nodes, the primary node is no longer present in the replica set, regardless of whether the primary node is closed, and the original primary node is demoted to the slave node. The entire replica set renders a read-only state at this time.

4. Number of nodes
A replica set requires at least two nodes, up to 12 nodes. One of them is the master node, and the rest is from the node and the quorum node. There are up to 7 nodes with voting rights. The more nodes you have, the greater the pressure to replicate, and the more you can increase the network load and slow down the performance of your cluster.
MongoDB has an odd number of official recommended nodes. The main reason is that the replica set is often distributed and may be located in different IDC. If even, the number of nodes per IDC can occur, so if the network fails, then each IDC node will not be able to select the primary node, resulting in all the situation is not available. For example, the number of nodes is 4, divided into 2 IDC, now the network between IDC failure, each IDC node is not greater than 2, so the replica set does not have a master node, become read-only.
5, from the type of node
Secondary: Standard slave node, can be copied, can vote, can be selected as the primary node
Secondary-only: cannot be the primary node, only as a slave node, to prevent some low performance nodes from becoming the primary node. The setting method is to place its priority = 0
Hidden: This kind of node is not able to be made by the client IP reference, can not be set as the primary node, but voting, generally used to back up data.
Delayed: You can specify a time delay to synchronize data from the primary node. Mainly used to back up data, if the real-time synchronization, the accidental deletion of data immediately synchronized to the slave node, recovery and can not recover.
Example:
cfg= {
"_id": <num>
"Host": "Priority": 0,
"Slavedelay": <seconds>
"Hidden": True
}
Rs.initiate (CFG);

Non-voting: Secondary node without the right to vote, pure backup data node. The setting method is to votes it = 0. This node is set up to take care of up to 12 nodes of the replica set, but there are a maximum of 7 nodes for the node to vote for.
Example:
Primary>cfg = rs.conf ()
Primary>cfg.members[3].votes = 0
Primary>cfg.members[4].votes = 0
Primary>cfg.members[5].votes = 0
Primary>rs.reconfig (CFG)

6. Read/write separation
You cannot read from a node by default, but you can set this option:
Secondary> Db.getmongo (). Setslaveok ();
This allows the read section to reduce the load on the primary node by using these slave nodes with the read option turned on.
As for writing, only the master node can be used forever.
7. Final consistency
Data written in the master node, the operation recorded in the log Oplog, from the node to poll the main node regularly, get Oplog, and then perform these operations on their own copies of the data, so as to ensure that the data from the node and the master node consistent, so there is a certain time lag is inevitable, MongoDB is the pursuit of eventual consistency.
Since "lag" is unavoidable, the need to do is to minimize this lag, mainly related to the following points:

Network latency: This is a problem with all distributed systems. What we can do is to minimize the network latency between replica set nodes.

Disk throughput: Data on a secondary node that is slower than the primary node will cause the secondary node to be hard to keep up with the rhythm of the primary node.

Concurrency: In the case of large concurrency, some time-consuming operations on the primary node block replication operations on the secondary node, causing the replication operation to keep up with the write load on the primary node. The workaround is to set the action by the write concern (see here: http://docs.mongodb.org/manual/core/write-concern/# Replica-set-write-concern) The default copy set write operation only cares about the primary node, but you can specify that the write operation is propagated to other secondary nodes at the expense of severely affecting the concurrency of the cluster.
Note: And there's a problem here. If a node that is concerned about the write operation goes down, the operation will be blocked until the node recovers.

Appropriate write concern: We often set the writer concern to unacknowledged write concern in order to improve the throughput of the cluster write operations, This causes the primary node to write quickly and the secondary node copy operation cannot keep up. The workaround and the 3rd is similar to the tradeoff between performance and consistency.

8. The way to deal with the replica set is not available
When a node fails, or because the network causes the remaining nodes to be less than half the number of nodes in the replica, the master node is no longer present in the entire replica set, and the original primary node is demoted to the slave node. The entire replica set renders a read-only state, which is no longer available.
In the event of this paralysis, I have not yet found a way to switch from node to primary, which may not exist. Because this is related to MongoDB's primary election strategy: If the situation is not secondary down, but the network is disconnected, then the nodes that are located in different IDC may each choose themselves as primary. This makes it necessary to deal with complex consistency issues after the network is restored. And the longer the disconnection, the more complex the time. So MongoDB chooses the strategy to not select Primary if the number of surviving nodes in the cluster is insufficient.
So
1) on the one hand, in order to avoid the existence of such a node less than half of the situation, in planning the replica set when the attention:
Sets the quorum node.
The total number of nodes is odd, and the master node is located in the IDC, with more than half of the number of nodes
2) Pay attention to the backup of the node, can restore the node if necessary
You can also create a completely new slave node in the same configuration, and the system automatically synchronizes the data after the replica set is restored. However, the guessing data volume is relatively large, time will be longer, so it is necessary to back up from the node at ordinary times.