- MongoDB CRUD Operations >
- Read Concern >
- Read Concern
"majority"
-
"majority"
¶
Read Concern "majority"
¶
On this page
A query with read concern "majority"
returns data that has been
acknowledged by a majority of the replica set members.
To use read concern level of "majority"
, replica
sets must use WiredTiger storage engine and
election protocol version 1
.
Starting in MongoDB 3.6, support for read concern
"majority"
is enabled by default. For MongoDB 3.6.1 -
3.6.x, 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.
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.
Causally Consistent Sessions¶
Read concern majority
is available for use with causally
consistent sessions.
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.
Disable Read Concern Majority¶
For 3-Member Primary-Secondary-Arbiter Architecture
For MongoDB 3.6.1 - 3.6.x, 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
three-member PSA shards.
Note
If you are using a deployment other than a 3-member PSA, you do not need to disable read concern majority.
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:
--enableMajorityReadConcern
command line option tofalse
.replication.enableMajorityReadConcern
configuration file setting tofalse
.
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 three-member PSA shards, disable to prevent the
storage cache pressure from immobilizing the deployment.
Disabling "majority"
read concern disables support
for Change Streams.