I. MongoDB replica set introduction MongoDB's replication mechanism is mainly divided into two types: Master-Slave (Master-Slave replication), which is no longer recommended to use the new features developed by ReplicaSet (replica set) MongoDB in version 1.6, the MongoDB replica set is recommended to be more powerful than the previous Master-Slave architecture. It supports asynchronous replication among multiple machines.
I. MongoDB Replica Set introduction MongoDB's replication mechanism is mainly divided into two types: Master-Slave (Master-Slave replication) which is no longer recommended to use Replica Set (Replica Set) the new features developed by MongoDB in version 1.6 are officially recommended to use MongoDB replica sets which are more powerful than the previous Master-Slave architecture and support asynchronous replication on multiple machines.
I. MongoDB Replica Set introduction MongoDB's replication mechanism is mainly divided into two types: Master-Slave (Master-Slave replication) which is no longer recommended to use Replica Set (Replica Set) new features developed in MongoDB 1.6 are officially recommended
The MongoDB replica set is more powerful than the previous Master-Slave architecture. It supports database data redundancy through asynchronous replication on multiple machines, greatly reducing the risk of single point of failure, in addition, automatic failover can be implemented. By default, only one machine can be used for read/write operations at a time, which provides strong data consistency and completely consistent data between databases. MongoDB Replica Set members are composed of a group of MongoDB process instances. In fact, the structure of the Replica Set is similar to a cluster and can be regarded as a cluster, because it does play the same role as the implementation of the cluster: if one of the nodes fails, other nodes will immediately take over the business without stopping the service.
Introduction to Replica Set members
MongoDB replica set members include the master node, slave node, and arbitration node. The following describes in detail.
1. the master node (Primary) is responsible for all write requests. The master node is the only one in the replica set that can accept write operation requests. The master node records all write operations on the oplog, you can copy oplog logs from a node and apply these operations to your node. By default, the client sends all its read requests to the master node, but you can also configure the slave node to have the ability to read data. A replica set can have only one master node at most. When it is unavailable (or is not qualified enough), you can use the Election Algorithm to select one from the slave node as the new master node.
2. Slave node (Secondaries)
Slave nodes maintain data consistency by copying master node data (by reading operation log files) l. In addition, slave nodes can have some special functions through some configurations (for example, do not allow them to have the right to vote or set their priority to zero. There are several common configurations: 2. 1. set Priority to 0 (Priority 0): If the Priority of a slave node is set to zero and the right to be elected is lost, the node cannot become the master node.
Note: a. Priority0 node does not have the right to vote, but has the right to vote. It can vote during the election. In addition, it will maintain a copy of the data on the master node and accept the read operation. B. The Priority0 node is very useful when deploying multiple data centers. You can place the master and slave nodes in the master data center and the priority0 node in the other node, which increases data security.
C. In addition, Priority0 can be used as a substitute member. When a member in the replica set is unavailable, it can be quickly replaced or set to Priority0 for a machine with poor hardware.
2.2.Hidden Member: The Hidden member is invisible to the client and therefore does not provide external read requests. This type of slave node only has a backup data.
Note: a. Hidden member also maintains a copy of data on the master node, but it is invisible to the client. db. isMaster () does not display Hideen members. The Hidden member is also a Priority0 member and only has the right to vote. B. the link between the Hidden member and other slave nodes is one-way communication. Other nodes cannot send requests to the Hidden member because the Hidden member is invisible to other nodes, in this way, the network communication pressure of the Hidden members is relatively small. We can use it for reporting or backup. If you want to back up data, we should ensure the network bandwidth between the Hidden node and the master node, minimize the replication lag time as much as possible, and maintain high data consistency between the two. 2.3 history snapshot Delayed (Delayed) Member: The slave node of this class does not maintain the same time as the data on the master node. It saves the existing data and has a historical snapshot.
A. the Delayed member reflects an earlier status of the master node. For example, if we set a Delayed member with an hour delay and the current status is, then a Delayed member only records data before. Due to the lag of data recorded by Delayed members, if errors occur during system upgrade or some operations, the data recorded by Delayed members can be used for Operation rollback. B. The Delayed member is both Priority0 and hidden. It also has the right to vote. C. delayed members synchronize data from logs on the master node in a "lagging" manner. Therefore, when we set the Delayed member's lagging time, it cannot be too large, operation logs are updated (a Capped Collection). If the delay time is set to be too long, operations recorded in operation logs may be updated very early, but it cannot be set too small. If it is too small, it will lose the significance of the existence of the Delayed member (it should be later than the system maintenance or upgrade window time ).
In the example of the five member replica sets below, a master node and four slave nodes both store a copy of data, one of which is set to a latency of 3600 seconds (one hour ), note that a Delayed member is also a Priority0 and Hidden member.
We can set a Delayed member as follows:
{"_ Id ": , "Host ": , "Priority": 0, "slaveDelay ": , "Hidden": true}
Note: 1. each slave node has a copy of the data on the master node. They use the master node (or slave node, as long as the operation log of the slave node is newer than the operation log recorded by the slave node) the information recorded in the operation log to asynchronously complete the write operation. 3. Arbitration node (
ArbiterThe submitter can become a member of the replica set. It does not store data and is mainly used for voting. For example, if the replica set has an even number of members, you can add an arbitrator. Note: You can add an arbitrator only when the number of nodes that can be voted in the replica set is an even number. As shown in the following example, a replica set originally has four members. At this time, we can add an arbitrator who does not store data.
Note: A replica set can have a maximum of 12 members, and only seven members can vote at a time. This restriction aims to reduce the voting time and improve the Failover efficiency.
Summary
The use of replica sets is transparent to users. The client can also get data from the slave node by configuring "read reference", but the data obtained may not be up-to-date, because the operation data on the master node may not be synchronized to the slave node, this phenomenon is called "final consistency", that is, if the data can be read from the node, MongoDB cannot guarantee "strong consistency" of the data ".
