Replica Set Secondary Members

This version of the documentation is archived and no longer supported. View the current documentation to learn how to upgrade your version of MongoDB.

A secondary maintains a copy of the primary's data set. To replicate data, a secondary applies operations from the primary's oplog to its own data set in an asynchronous process. [1] A replica set can have one or more secondaries.

The following three-member replica set has two secondary members. The secondaries replicate the primary's oplog and apply the operations to their data sets.

Diagram of a 3 member replica set that consists of a primary and two secondaries.

Although clients cannot write data to secondaries, clients can read data from secondary members. See Read Preference for more information on how clients direct read operations to replica sets.

A secondary can become a primary. If the current primary becomes unavailable, the replica set holds an election to choose which of the secondaries becomes the new primary.

In the following three-member replica set, the primary becomes unavailable. This triggers an election where one of the remaining secondaries becomes the new primary.

Diagram of an election of a new primary. In a three member replica set with two secondaries, the primary becomes unreachable. The loss of a primary triggers an election where one of the secondaries becomes the new primary

click to enlarge

See Replica Set Elections for more details.

You can configure a secondary member for a specific purpose. You can configure a secondary to:

Prevent it from becoming a primary in an election, which allows it to reside in a secondary data center or to serve as a cold standby. See Priority 0 Replica Set Members.
Prevent applications from reading from it, which allows it to run applications that require separation from normal traffic. See Hidden Replica Set Members.
Keep a running "historical" snapshot for use in recovery from certain errors, such as unintentionally deleted databases. See Delayed Replica Set Members.

[1]

Starting in version 4.2, secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. These slow oplog messages:

Are logged for the secondaries in the diagnostic log.
Are logged under the REPL component with the text applied op: <oplog entry> took <num>ms.
Do not depend on the log levels (either at the system or component level)
Do not depend on the profiling level.
May be affected by slowOpSampleRate, depending on your MongoDB version:
- In MongoDB 4.2, these slow oplog entries are not affected by the slowOpSampleRate. MongoDB logs all slow oplog entries regardless of the sample rate.
- In MongoDB 4.4 and later, these slow oplog entries are affected by the slowOpSampleRate.

The profiler does not capture slow oplog entries.

Back

Replica Set Primary

Priority 0 Replica Set Members