• MongoDB CRUD Operations >
• Read Concern >
• Read Concern "majority"

Read Concern "majority"

"majority"

For read operations not associated with multi-document transactions, read concern "majority" guarantees that the data read has been acknowledged by a majority of the replica set members (i.e. the documents read are durable and guaranteed not to roll back).

For operations in multi-document transactions, read concern "majority" provides its guarantees only if the transaction commits with write concern “majority”. Otherwise, the "majority" read concern provides no guarantees about the data read in transactions.

Regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.

Performance

Each replica set member maintains, in memory, a view of the data at the majority-commit point; the majority-commit point is calculated by the primary. To fulfill read concern "majority", the node returns data from this view and is comparable in performance cost to other read concerns.

Availability

Read concern "majority" is available for use with or without causally consistent sessions and transactions.

Warning

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:

• The write concern "majority" can cause performance issues if a secondary is unavailable or lagging. For advice on how to mitigate these issues, see Mitigate Performance Issues with PSA Replica Set.
• If you are using a global default "majority" and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data.

Example

Consider the following timeline of a write operation Write₀ to a three member replica set:

Note

For simplification, the example assumes:

• All writes prior to Write₀ have been successfully replicated to all members.
• Write_prev is the previous write before Write₀.
• No other writes have occured after Write₀.

Time	Event	Most Recent Write	Most Recent w: “majority” write
t0	Primary applies Write0	Primary: Write0 Secondary1: Writeprev Secondary2: Writeprev	Primary: Writeprev Secondary1: Writeprev Secondary2: Writeprev
t1	Secondary1 applies write0	Primary: Write0 Secondary1: Write0 Secondary2: Writeprev	Primary: Writeprev Secondary1: Writeprev Secondary2: Writeprev
t2	Secondary2 applies write0	Primary: Write0 Secondary1: Write0 Secondary2: Write0	Primary: Writeprev Secondary1: Writeprev Secondary2: Writeprev
t3	Primary is aware of successful replication to Secondary1 and sends acknowledgement to client	Primary: Write0 Secondary1: Write0 Secondary2: Write0	Primary: Write0 Secondary1: Writeprev Secondary2: Writeprev
t4	Primary is aware of successful replication to Secondary2	Primary: Write0 Secondary1: Write0 Secondary2: Write0	Primary: Write0 Secondary1: Writeprev Secondary2: Writeprev
t5	Secondary1 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: “majority” write	Primary: Write0 Secondary1: Write0 Secondary2: Write0	Primary: Write0 Secondary1: Write0 Secondary2: Writeprev
t6	Secondary2 receives notice (through regular replication mechanism) to update its snapshot of its most recent w: “majority” write	Primary: Write0 Secondary1: Write0 Secondary2: Write0	Primary: Write0 Secondary1: Write0 Secondary2: Write0

Then, the following tables summarizes the state of the data that a read operation with "majority" read concern would see at time T.

Read Target	Time T	State of Data
Primary	Before t3	Data reflects Writeprev
Primary	After t3	Data reflects Write0
Secondary1	Before t5	Data reflects Writeprev
Secondary1	After t5	Data reflects Write0
Secondary2	Before or at t6	Data reflects Writeprev
Secondary2	After t6	Data reflects Write0

Storage Engine Support

Read concern "majority" is available for the WiredTiger storage engine.

Tip

The serverStatus command returns the storageEngine.supportsCommittedReads field which indicates whether the storage engine supports "majority" read concern.

Read Concern "majority" and Transactions

Note

You set the read concern at the transaction level, not at the individual operation level. To set the read concern for transactions, see Transactions and Read Concern.

For operations in multi-document transactions, read concern "majority" provides its guarantees only if the transaction commits with write concern “majority”. Otherwise, the "majority" read concern provides no guarantees about the data read in transactions.

Read Concern "majority" and Aggregation

Starting in MongoDB 4.2, you can specify read concern level "majority" for an aggregation that includes an $out stage.

In MongoDB 4.0 and earlier, you cannot include the $out stage to use "majority" read concern for the aggregation.

Read Your Own Writes

Changed in version 3.6.

Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes request acknowledgement.

Prior to MongoDB 3.6, in order to read your own writes you must issue your write operation with { w: "majority" } write concern, and then issue your read operation with primary read preference, and either "majority" or "linearizable" read concern.

Primary-Secondary-Arbiter Replica Sets

Starting in MongoDB 5.0, enableMajorityReadConcern and --enableMajorityReadConcern cannot be changed and are always set to true due to storage engine improvements.

In earlier versions of MongoDB, enableMajorityReadConcern and --enableMajorityReadConcern are configurable and can be set to false to prevent storage cache pressure from immobilizing a deployment with a three-member primary-secondary-arbiter (PSA) architecture.

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:

• The write concern "majority" can cause performance issues if a secondary is unavailable or lagging. For advice on how to mitigate these issues, see Mitigate Performance Issues with PSA Replica Set.
• If you are using a global default "majority" and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data.

←   Read Concern "available" Read Concern "linearizable"  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.