Read Concern "majority"¶
On this page本页内容
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.
You can disable read concern "majority" for a deployment with a three-member primary-secondary-arbiter (PSA) architecture;
however, this has implications for change streams (in MongoDB 4.0 and earlier only) and transactions on sharded clusters. For more information, see Disable Read Concern Majority.
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.
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.在版本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
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.
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:
--enableMajorityReadConcerncommand line option tofalse.replication.enableMajorityReadConcernconfiguration file setting tofalse.
To check if read concern “majority” is disabled, You can run db.serverStatus() on the mongod instances and check the storageEngine.supportsCommittedReads field. If false, read concern “majority” is disabled.
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 shard, disable to prevent the storage cache pressure from immobilizing the deployment.
Change Streams
Disabling "majority" read concern disables support for Change Streams for MongoDB 4.0 and earlier. For MongoDB 4.2+, disabling read concern "majority" has no effect on change streams availability.
Transactions
Disabling "majority" read concern affects support for transactions on sharded clusters. Specifically:
- A transaction cannot use read concern
"snapshot"if the transaction involves a shard that has disabled read concern “majority”. - A transaction that writes to multiple shards errors if any of the transaction’s read or write operations involves a shard that has disabled read concern
"majority".
However, it does not affect transactions on replica sets. For transactions on replica sets, you can specify read concern "majority" (or "snapshot" or "local" ) for multi-document transactions even if read concern "majority" is disabled.
Rollback Considerations
Disabling "majority" read concern prevents collMod commands which modify an index from rolling back. If such an operation needs to be rolled back, you must resync the affected nodes with the primary node.