On this page
A replica set in MongoDB is a group of Replication provides redundancy and increases data availability. With multiple copies of data on different database servers, replication provides a level of fault tolerance against the loss of a single database server. In some cases, replication can provide increased read capacity as clients can send read operations to different servers. Maintaining copies of data in different data centers can increase data locality and availability for distributed applications. You can also maintain additional copies for dedicated purposes, such as disaster recovery, reporting, or backup. A replica set is a group of The primary node receives all write operations. A replica set can have only one primary capable of confirming writes with
The secondaries replicate the primary's oplog and apply the operations to their data sets such that the secondaries' data sets reflect the primary's data set. If the primary is unavailable, an eligible secondary will hold an election to elect itself the new primary. For more information on secondary members, see Replica Set Secondary Members. In some circumstances (such as you have a primary and a secondary but cost constraints prohibit adding another secondary), you may choose to add a An arbiter will always be an arbiter whereas a primary may step down and become a secondary and a secondary may become the primary during an election. Secondaries replicate the primary's oplog and apply the operations to their data sets asynchronously. By having the secondaries' data sets reflect the primary's data set, the replica set can continue to function despite the failure of one or more members. For more information on replication mechanics, see Replica Set Oplog and Replica Set Data Synchronization. Starting in version 4.2 (also available starting in 4.0.6), secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. These slow oplog messages:
The profiler does not capture slow oplog entries. Replication lag refers to the amount of time that it takes to copy (i.e. replicate) a write operation on the primary to a secondary. Some small delay period may be acceptable, but significant problems emerge as replication lag grows, including building cache pressure on the primary. Starting in MongoDB 4.2,
administrators can limit the rate at which the primary applies its writes with the goal of keeping the By default, flow control is
NoteFor flow control to engage, the replica set/sharded cluster must have: featureCompatibilityVersion (FCV) of With flow control enabled, as the lag grows close to the For more information, see Check the Replication Lag and Flow Control. When a primary does not communicate with the other members of the set for more than the configured The replica set cannot process write operations until the election completes successfully. The replica set can continue to serve read queries if such queries are configured to run on secondaries while the primary is offline. The median time before a cluster elects a new primary should not typically exceed 12 seconds, assuming default
Lowering
the Your application connection logic should include tolerance for automatic failovers and the subsequent elections. Starting in MongoDB 3.6, MongoDB drivers can detect the loss of the primary and automatically retry certain write operations a single time, providing additional built-in handling of automatic failovers and elections:
Starting in version 4.4, MongoDB provides mirrored reads to pre-warm electable secondary members' cache with the most recently accessed data. Pre-warming the cache of a secondary can help restore performance more quickly after an election. To learn more about MongoDB’s failover process, see:
By default, clients read from the primary [1]; however, clients can specify a read preference to send read operations to secondaries. Asynchronous replication to secondaries means that reads from secondaries may return data that does not reflect the state of the data on the primary. Multi-document transactions that contain read operations must use read preference For information on reading from replica sets, see Read Preference. Depending on the read concern, clients can see the results of writes before the writes are durable:
For operations in a multi-document transaction, when a transaction commits, all data changes made in the transaction are saved and visible outside the transaction. That is, a transaction will not commit some of its changes while rolling back others. Until a transaction commits, the data changes made in the transaction are not visible outside the transaction. However, when a transaction writes
to multiple shards, not all outside read operations need to wait for the result of the committed transaction to be visible across the shards. For example, if a transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, an outside read at read concern For more information on read isolations, consistency and recency for MongoDB, see Read Isolation, Consistency, and Recency. Mirrored reads reduce the impact of primary elections following an outage or planned maintenance. After a failover in a replica set, the secondary that takes over as the new primary updates its cache as new queries come in. While the cache is warming up performance can be impacted. Starting in version 4.4, mirrored reads pre-warm the caches of The size of the subset of NoteMirrored reads do not affect the primary's response to the client. The reads that the primary mirrors to secondaries are "fire-and-forget" operations. The primary doesn't await responses. Mirrored reads support the following operations:
Starting in MongoDB 4.4, mirrored reads are enabled by default and use a default
With a sampling rate greater than Consider a replica set that consists of one primary and two electable secondaries. If the primary receives To change the sampling rate for mirrored reads, set the
For details,
see Starting in MongoDB 4.4, the
Starting in MongoDB 4.0, multi-document transactions are available for replica sets. Multi-document transactions that contain read operations must use read preference Until a transaction commits, the data changes made in the transaction are not visible outside the transaction. However, when a
transaction writes to multiple shards, not all outside read operations need to wait for the result of the committed transaction to be visible across the shards. For example, if a transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, an outside read at read concern Starting in MongoDB 3.6, change streams are available for replica sets and sharded clusters. Change streams allow applications to access real-time data changes without the complexity and risk of tailing the oplog. Applications can use change streams to subscribe to all data changes on a collection or collections. Replica sets provide a number of
options to support application needs. For example, you may deploy a replica set with members in multiple data centers, or control the outcome of elections by adjusting the See Priority 0 Replica Set Members, Hidden Replica Set Members and Delayed Replica Set Members for more information. |