Shulou(Shulou.com)06/01 Report--

I. introduction to replication

Replication is the process of synchronizing data between multiple servers.

Replication not only provides redundancy for data, but also improves the availability of data. Because there are multiple data mirrors on different database servers, replication can effectively prevent data loss caused by the failure of a single server. Replication can also help us recover data from hardware failures or service outages. We can also use it for disaster recovery, reporting, or backup by adding replication nodes.

In some cases, we can improve the performance of reads by copying. The client can send read and write requests to different servers. We can also do remote redundancy by setting up distributed replication nodes in other data centers to further improve availability.

Replication in MongoDB

A replication set consists of a set of mongod instances that have the same dataset. One of the nodes is the master node (Primary), on which all write requests are completed. The other nodes are all slave nodes (secondary), which receive the operations from the master node and apply them to ensure that they are consistent with the data set of the master node.

The master node receives all writes from the client. A replication set can have only one primary node. Because only one member in a replication set can receive writes, the replication set provides a strict consistency check for all reads from the primary node. The master node supports the implementation of replication by recording changes in all datasets to oplog.

The slave node copies the oplog on the master node and applies these operations to modify its own dataset to ensure that the slave node's dataset is consistent with the master node's dataset. Once the master node is unavailable, the replica set elects a slave node as the new master node. By default, the client reads from the master node, but the client can also send the read operation to the slave node by specifying the replication set read option. It should be noted that when reading from the node, the data obtained may not be the value on the master node at this time.

We can also add an additional mongod instance as a voting node for the replica set. The voting node does not contain data sets, and the role of the voting node is only to participate in the voting process. When the number of members of the replica set is even, adding a voting node can prevent a draw and elect a new primary node through a majority of votes. Because the voting node only provides the voting function, there is no need for a dedicated physical machine.

The voting node will be used for voting only. When the master node is demoted to a slave node, the other slave node will be elected as the master node in the election.

Asynchronous replication

The process of applying an operation from a slave node to the master node is asynchronous. Because the slave node applies the operation after the master node, the replication set can continue to run when some members are missing. In this case, however, the data returned from the node to the client may not be up-to-date.

Automatic failover

When the primary node is unable to communicate with other members of the replication set for more than 10 seconds, the replication set attempts to promote another member as the new primary node. At this point, the first slave node to get a majority vote will be promoted to the master node.

Other features

Replication sets provide options to support the needs of practical applications. For example, distribute a replication set across multiple data centers, or set up a priority to control the results of the election. Replication sets also support the use of members for reporting, disaster recovery, or backup.

II. Introduction to the concept of replication replication set members

The replication set of MongoDB consists of a set of mongod instances and provides data redundancy and high availability. There are the following types of members in the replication set:

Primary.

The master node receives all write requests.

Secondaries.

The slave node keeps its data set consistent with the master node by applying the data change operation from the master node. Slave nodes can also respond to special requirements by adding additional parameter configurations. For example, the slave node can be non-voting or priority 0.

We can also set up a voting node for the replication set. The voting node itself does not contain a dataset. However, once the current master node is not available, the voting node will participate in the voting for the new master node election.

A replication set can have up to 12 members. [1] but at the same time, only seven of them can vote.

A replica set requires at least these members: a master node, a slave node, and a voting node. But in most cases, we will maintain three nodes that own the dataset: one master node and two slave nodes.

Replication set master node

In a replication set, the primary node is the only node that can receive write requests. MongoDB writes on the primary node and logs these operations to the oplog of the primary node. The slave node copies the oplog to its native and applies these operations to its own dataset.

In a replication set with the following three members, the master node receives all write requests, while the slave node copies the oplog to the local machine and applies these operations on its own dataset.

Any member of the replication set can receive read requests. By default, however, the application connects directly to the read operation on the primary node.

A replication set can have at most one primary node. Once the current primary node is unavailable, the replica set elects a new primary node.

In a replica set with the following three members, once the current master node is unavailable, the election mechanism will be triggered and a new master node will be elected among the remaining slave nodes.

Replication set slave node

The dataset of the slave node is consistent with that of the master node. The slave node copies the oplog on the master node to the local machine and asynchronously applies these operation records to its own dataset. Each replication set can have multiple slave nodes.

The following three-member replication set has two slave nodes. These slave nodes copy the oplog on the master node and apply it to their own dataset.

Although the client cannot write on the slave node, it can read.

Slave nodes can be promoted to master nodes. Once the existing master node is unavailable, the replication set will initiate an election to select which slave node will be promoted to the new master node.

In a replica set with the following three members, once the current master node is unavailable, the election mechanism will be triggered and a new master node will be elected among the remaining slave nodes.

We can use the slave node for special requirements by modifying the parameters. For example:

We can permanently reside as a slave node or use it as a cold backup by prohibiting the promotion of a slave node to a master node.

We can allow some applications that require traffic isolation to read on the slave node by prohibiting the application from reading on it.

We can prevent misoperation or errors such as erroneous deletion by setting a "delayed backup node".

Replication set members with priority 0

Once the priority is set to 0, the slave node cannot be promoted to the master node. A member with a priority of 0 does not trigger the election. In addition, this node is no different from other slave nodes. the slave node with priority 0 has the same data set as the master node and can accept read requests and vote at the same time. By setting the priority of the slave node to 0 to prevent it from being promoted to the master node, it can play a good role in the distributed data center structure.

In the following three-member replication set, one master node and one slave node are located in one data center, and another slave node with a priority of 0 that cannot be promoted to the master node is in another data center.

Use a member with a priority of 0 as a backup node

In many cases, we may not need to prepare a backup node with a priority of 0. However, in some situations where the geographical distribution of the hardware environment or architecture is more changeable, a backup node with a priority of 0 can well ensure that qualified members are promoted to the primary node.

A backup node with a priority of 0 with special hardware configuration or system optimization configuration can also effectively provide services for special needs. For example, you can set the priority to 0 so that it cannot be promoted to the primary node.

If we already have seven voting nodes in our replica set, please set the other nodes not to vote.

Nodes with priority 0 and failover

When configuring a node with a priority of 0, we need to consider possible failover situations, such as network failures. When it comes to attention, we need to make sure that there are enough nodes in the primary data center that can participate in voting and elections, and that they have members who can successfully become the master node.

Hide Node

The hidden node has the same dataset as the master node, but it is not visible to the application. Hidden nodes can be well isolated from other nodes in the replication set and respond to special needs. The hidden node should also be a node with a priority of 0 that cannot be promoted to the primary node. The function db.isMaster () will not list hidden nodes. Hidden nodes can vote in the election.

In the five-node replication set described below, all four slave nodes have the same dataset as the master node, but one of the slave nodes is a hidden node.

Reading exercise

The client will not distribute the read request to the hidden node, even if we set the replication set read option. These hidden nodes will not receive requests from the application. We can dedicate hidden nodes to report nodes or backup nodes. The delay node should also be a hidden node.

In a sharding cluster, mongos will not communicate with hidden nodes.

vote

In the election of the replica set, the hidden node will vote. When shutting down a hidden node, make sure that there are enough available nodes in the replication set to elect, in case the demotion of the primary node causes the replication set to be unavailable.

Using hidden nodes for backups prevents the application from becoming unavailable when we use db.fsyncLock () and db.fsyncUnlock () operations to add or unlock mongod instances during the backup process.

Delay node

The deferred node will also replicate data from the master node in the replication set, but the dataset in the delayed node will be later than the data from the master node in the replication set. For example, it is 09:52, and if the deferred node is delayed by an hour, there will be no operations after 08:52 in the dataset of the deferred node.

Because the data set of the delay node is delayed, it can help us to recover the data in human misoperation or other unexpected circumstances. For example, when the application upgrade fails, or when the table and database are deleted by misoperation, we can restore the data through the deferred node.

Behavior

Delay nodes achieve the effect of delay by delaying the application of operations in oplog. When we choose to delay frequently, we need to consider the following:

Must be greater than or equal to your maintenance window.

Must be less than the storage capacity of oplog

Slice

In a sliced cluster, the delay node effect is limited when the balancer balancer is turned on. Because of the delayed replication segment of the node, and if the segment migration has been carried out within the delayed period, the delayed node in the replication set will not be able to provide effective help for restoring the fragmentation cluster.

Examples

In the five-member replica set described below, the master node and all slave nodes have copies of the dataset. One of the slave nodes delays applying the operation in oplog by 3600 seconds (1 hour). This delay node is also a hidden node and a node with a priority of 0.

Configuration mode

The delay node needs to set priority to 0, hidden to true, and slaveDelay to the time you want to delay (in seconds):

{"_ id":, "host":, "priority": 0, "slaveDelay":, "hidden": true}

Voting node

The voting node does not contain a copy of the dataset in the replication set and cannot be promoted to the primary node. There may be multiple voting nodes in the replica set to vote for the election of a new master. The existence of voting nodes enables the replication set to exist in an even number of nodes without the need for additional nodes for the replication set.

Be careful

Do not run the voting node on the master node or slave node machine of the replication set.

Add a voting node only when the replica set has even members. If a new voting node is added to a replica set with an odd number of replica set members, the replica set may encounter an election stalemate.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.