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

MongoDB Manual (Version 4.2) > Replication

A replica set in MongoDB is a set of mongod processes that maintain the same data set. Replica sets provide redundancy and high availability, and this is the basis for all production deployments. This section describes replication in MongoDB and the components and architecture of replica sets, and provides tutorials for common tasks of replica sets.

No 1 redundancy and data

Replication provides redundancy and increases data availability. For multiple data replicas on different database servers, replication provides a certain degree of fault tolerance to prevent the failure of a single database server.

In some cases, replication can improve read performance because clients can send reads to different servers. Maintaining data replicas in different data centers can improve the data localization and availability of distributed applications. You can also maintain additional copies for special purposes, such as disaster recovery, reporting, or backup.

A replica set of No 2 MongoDB is a set of mongod instances that maintain the same data set. The replica set contains multiple data bearer nodes and an optional quorum node. In the data bearer node, there is and only one member is the primary node, and the other nodes are replica nodes.

The master node receives all write operations. Only one master node in a replica set can confirm write operations with the {w: "majority"} write concern level; although in some cases, another instance of mongod can temporarily consider itself the master node. [1] the master node records all changes in its data set to the operation log, namely oplog. For more information about master node operations, see replica set Master Node.

The replica node replicates the oplog of the primary node and applies these operations to their dataset so that the dataset of the replica node can reflect the dataset of the primary node. If the primary node is not available, a candidate replica node will initiate an election and make it the new primary node. For more information about replica members, see replica set replica members.

In some cases (for example, you have a master node and a replica node, but another replica node cannot be added due to cost constraints), you can choose to add an mongod instance as a quorum node to a replica set. The arbitration node participates in the election but does not hold data (that is, does not provide data redundancy). For more information about quorum nodes, see replica set quorum nodes.

The arbitration node can always be the arbitration node, but in the election process, the primary node may be downgraded to the replica node, and the replica node may also be upgraded to the primary node.

No 3 Asynchronous replication replica nodes replicate the oplog of the primary node and asynchronously apply operations to their datasets. By having the dataset of the replica node reflect the dataset of the primary server, the replica set can continue to run if one or more members fail.

For more information about replication mechanisms, see replica set Oplog and replica set data synchronization.

Slow operation

Starting with version 4.2 (which is also feasible from 4.0.6), replica members of the replica set record slow operation entries in the oplog that have been applied for longer than the slow operation threshold. This slow oplog information is recorded in the diagnostic log of the replica node, and its path is in the text applied op: took ms of the REPL component. These slow log entries depend only on the slow operation threshold. They do not depend on the log level (whether system or component level), the filtering level, or the slow operation sampling ratio. The filter does not capture slow log entries.

Replication delay and flow control

Replication latency refers to the time it takes to copy (that is, copy) the write operation of the primary node to the replica node. Some small delays may be acceptable, but as replication latency increases, serious problems can occur, including cache pressure on the primary node.

Starting with MongoDB 4.2, administrators can limit the speed at which writes are applied to the primary node in order to keep the majority committed latency below the maximum value of the configurable parameter flowControlTargetLagSeconds.

Flow control is enabled by default.

Note:

For flow control, the replication set / sharding cluster must meet the following requirements: the parameter featureCompatibilityVersion (FCV) is set to 4.2 and majority read concerns are enabled. That is, if FCV is not 4.2, or if the read concern majority is disabled, then enabling flow control will not work.

When flow control is enabled, when the delay is fast approaching the number of seconds specified by the flowControlTargetLagSeconds parameter, the write operation on the primary node must first obtain a permit (tickets) before the write lock can be acquired. By limiting the number of permits issued per second, the flow control mechanism can keep the delay below the target value.

For more information, see checking replication delay and flow Control.

No 4 automatic failover when the primary node cannot communicate with other nodes in the cluster for longer than the time limit configured by the parameter electionTimeoutMillis (default 10s), a candidate replica node will initiate an election to recommend itself as the new primary node. The cluster will attempt to complete the election of a new primary node and resume normal operation.

The replica set cannot handle writes until the election is successful. If read requests are configured to run on the replica node, the replica set can continue to process these requests when the primary node goes offline.

Assuming the default replica configuration option, the intermediate transition time for the cluster to select a new primary node should not exceed 12 seconds. This includes the time to mark the primary node as unavailable, initiate, and complete an election. You can adjust this time period by modifying the settings.electionTimeoutMillis replication configuration option. Factors such as network latency may extend the time it takes to complete the replica set election, thus affecting the time it takes for your cluster to run without a primary node. These factors depend on your actual cluster architecture.

Reducing the electionTimeoutMillis replication configuration option from the default of 10000 (10 seconds) allows faster detection of primary node failures. However, due to factors such as temporary network delays, clusters may initiate elections more frequently, even if the primary node is otherwise healthy. This may increase the likelihood that write operations at the w: 1 level will be rolled back.

Your application connection logic should include fault tolerance for automatic failover and subsequent elections. Starting with MongoDB 3.6, the MongoDB driver can detect the loss of the primary node and automatically retry some writes once, providing additional built-in processing for automatic failover and election:

MongoDB 4.2 compatible drivers enable rewritable MongoDB 4.0 and 3.6 compatible drivers by default must explicitly enable rewritable by including retryWrites=true in the connection string.

See replica set elections for complete information about replica set elections.

To learn more about MongoDB failure handling, see:

Replica set election can retry to write back No 5 read operation read preference during a replica set failure

By default, the client reads from the primary node; however, the client can define a read preference to send the read operation to the replica node.

Replication to the replica node asynchronously means that the data returned by reading from the replica node does not reflect the state of the data on the primary node.

Multi-document transactions that include read operations must use the read preference primary. All operations must be routed to the same member node in a given transaction.

For more information about replica set reads, see read preferences.

Data visibility

Depending on the read concern, the client can see the write result before the write persistence:

Regardless of the write concern level of writing, other clients that use the read concern level of "local" or "available" can view the results of the write by the client that initiated the write before confirming that the write was successful. A client with a read concern level of "local" or "available" is used to read data that may be rolled back later during a replica set failover.

For operations in a multi-document transaction, when the transaction commits, all data changes made in the transaction are saved and visible outside the transaction. That is, the transaction does not commit some changes when it rolls back other changes.

Data changes made in the transaction are not visible outside the transaction until the transaction is committed.

However, when a transaction is written to multiple shards, not all external read operations need to be committed and the results of the transaction are visible in the shard. For example, if a transaction is committed and write 1 can be seen on slice a, but write 2 cannot be seen on slice B, then a read with an external read focus on "local" can read the result of write 1 without seeing write 2.

For more information, see Read Isolation, Consistency, and Recency.

No 6 transaction

Since MongoDB 4. 0, replica sets support multiple document transactions.

Multi-document transactions that include read operations must use the read preference primary. All operations in a given transaction must be routed to the same member node.

Data changes made in the transaction are not visible outside the transaction until the transaction is committed.

However, when a transaction is written to multiple shards, not all external read operations need to be committed and the results of the transaction are visible in the shard. For example, if a transaction is committed and write 1 can be seen on slice a, but write 2 cannot be seen on slice B, then a read with an external read focus on "local" can read the result of write 1 without seeing write 2.

No7 change flow

Since MongoDB 3. 6, replica sets and shard clusters support change flows. The change flow allows applications to access real-time data changes without tracking the complexity and risks of oplog. Applications can use change flows to subscribe to all data changes on one or more collections.

No8 add-on function

The replica set provides a number of options to support the needs of the application. For example, you can use members in multiple data centers to deploy a replica set, or control the election results by adjusting the members.priority of some members. Replica sets also support dedicated members for reporting, disaster recovery, or backup functions.

For more information, see replica set members with priority 0, hide replica set members, and deferred replica set members.

Note:

(1, 2) in some scenarios, two nodes in a replication set may think of them as primary nodes, but at most, one of them will be able to complete write operations with {w: "majority"} concerns. The node that can write {w: "majority"} is the current master node, while the other node is the original master node, usually due to the network partition that it is not aware of its degradation. When this happens, the client connected to the original primary node may observe obsolete data even though it has requested a read preference primary, and new writes to the original primary node will eventually be rolled back.

Translator: Li Zhengyang

Member of MongoDB Chinese Community Translation team

Currently engaged in DBA position in the traditional financial industry, 5 years + working experience, mainly responsible for the company's oracle/mongodb/es/redis database and data center monitoring platform operation and maintenance work, oracle ocp,MongoDB certification experts, RHCE, at this stage, great interest in open source distributed database, cloud computing and other fields; usually like playing badminton, watching movies, etc.

Original text link:

Https://docs.mongodb.com/manual/replication/

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.