Navigation

Read Concern "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).

However, 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.

To use read concern level of "majority", replica sets must use WiredTiger storage engine.

For MongoDB 4.0.3+ (and 3.6.1+), you can disable read concern "majority". For more information, see Disable Read Concern Majority.

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.

Example

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

Note

For simplification, the example assumes:

  • All writes prior to Write0 have been successfully replicated to all members.
  • Writeprev is the previous write before Write0.
  • No other writes have occured after Write0.
Timeline of a write operation to a three member replica set.
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.

Timeline of a write operation to a three member replica set.
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.

Causally Consistent Sessions

Read concern majority is available for use with causally consistent sessions.

Read Concern "majority" and Transactions

For "local" and "majority" read concern, MongoDB may provide stronger isolation guarantees than specified. Specifically, in MongoDB 4.0, all multi-documents transactions have "snapshot" isolation.

In future versions of MongoDB, the server will optimize around the specified read concern (isolation level) instead of providing stronger isolation guarantees than explicitly specified.

As such, if stronger guarantees than "local" and "majority" read concern are needed, explicitly specify the appropriate read concern instead of relying on MongoDB to promote the read concern level.

Note

You set the read concern at the transaction level, not at the individual operation level. To set the read concern for transactions, see Transaction Options (Read Concern/Write Concern/Read Preference).

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 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, you must have issued your write operation with { w: "majority" } write concern and then use either "majority" or "linearizable" read concern for the read operations to ensure that a single thread can read its own writes.

Disable Read Concern Majority

For 3-Member Primary-Secondary-Arbiter Architecture

For MongoDB 4.0.3+ (and 3.6.1+ [1]), you can disable read concern "majority" if you have a three-member replica set with a primary-secondary-arbiter (PSA) architecture or a sharded cluster with a three-member PSA shards.

With a three-member PSA architecture, the cache pressure will increase if any data bearing node is down. To prevent the storage cache pressure from immobilizing a deployment with a PSA architecture, you can disable read concern by setting either:

Important

In general, avoid disabling "majority" read concern unless necessary. However, if you have a three-member replica set with a primary-secondary-arbiter (PSA) architecture or a sharded cluster with a three-member PSA shards, disable to prevent the storage cache pressure from immobilizing the deployment.

Disabling "majority" read concern disables support for Change Streams.

Disabling "majority" does not affect multi-document transactions; i.e. you can specify read concern "majority" for transactions even if read concern "majority" is disabled.

[1]For MongoDB 3.6 discussion, see Disable Read Concern Majority.