For read operations not associated with multi-document
transactions, read concern
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.
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
"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.
Consider the following timeline of a write operation Write 0 to a three member replica set:
For simplification, the example assumes:
- All writes prior to Write 0 have been successfully replicated to all members.
- Write prev is the previous write before Write 0.
- No other writes have occured after Write 0.
Most Recent Write
Most Recent w: "majority" write
Primary applies Write 0
Primary: Write 0