Read concern and causal consistency with secondary reads
Parent: MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Read concern and causal consistency with secondary reads. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Read preference selects eligible replica-set members; directing reads to secondaries can return stale data because replication from the primary is asynchronous. (high confidence) [source]
- For durable causal consistency, execute dependent operations in a causally consistent client session with majority read concern and majority write concern. This combination guarantees read-your-writes, monotonic reads, monotonic writes, and writes-follow-reads, including when reads use secondaries. (high confidence) [source]
Problems, failure modes and limitations
- A causally consistent read cannot depend on an unacknowledged w:0 write because the session receives no operation time for that write. (high confidence) [source]
Comparisons and alternatives
- MongoDB 8.0 changed majority-write acknowledgment to follow oplog persistence rather than completion of secondary application. An immediate secondary read outside a causally consistent session can therefore miss the acknowledged update. (medium confidence) (verified as of 2026-10-14) [source]
- Majority read concern uses a committed timestamped snapshot rather than polling every replica for the latest value. Without an additional causal-time requirement it usually need not wait for new writes, although snapshot availability and replication lag can cause blocking. (low confidence) [source]
Facts and statements
- Majority read concern alone does not mean reading the latest primary state: it can return an older majority-committed snapshot on the selected member. (high confidence) [source]
- A majority write followed in the same causal session by a majority read with secondary read preference reflects the preceding write; if the selected secondary has not reached the dependency time, the read waits. (high confidence) [source]
- Drivers track operationTime in the client session and send it as readConcern.afterClusterTime on subsequent supported causally consistent commands. They also gossip clusterTime; applications should use the session API to carry this causal context. (high confidence) [source]
- Applications must serialize operations within a client session. To preserve dependencies across sessions, explicitly advance the receiving session operation time and cluster time from the originating session. (high confidence) [source]
- Causal consistency does not isolate a session from concurrent outside writes. A subsequent read may include intervening writes, so these guarantees should not be treated as snapshot isolation or a guarantee of the latest unrelated write. (medium confidence) [source]
- Do not assume that enabling causal sessions makes weaker concern settings durable: MongoDB documents partial guarantees for weaker combinations, and Jepsen historically found that causal sessions with weaker read/write concerns could violate expected causal behavior. (high confidence) [source]
- Independent Internetware research tested MongoDB 4.2.3 using formal CC, CCv, and CM checking and reported preliminary results supporting the majority-read/majority-write requirements under faults; this is historical test evidence, not validation of current server versions. (low confidence) [source]
- Read-containing multi-document transactions must use primary read preference; a causal session supporting secondary reads does not make a secondary eligible for such transaction reads. (low confidence) [source]
- Read preference selects eligible replica-set members; read concern controls the data a selected member may return. A secondary can lag the primary, and majority read concern alone does not guarantee the newest write is visible. (medium confidence) [source]
- A causally dependent secondary read may wait for the secondary to reach the required causal time. Causal consistency trades waiting for dependency order; it does not make asynchronous replication instantaneous. (high confidence) [source]
- Operations in different client sessions need an explicit causal handoff: advance the receiving session's operation time and cluster time from the producing session. An acknowledgment or application notification alone does not transfer that session context. (medium confidence) [source]
- Do not assume that enabling a causal session repairs weaker concerns. MongoDB documents fewer durable guarantees with local reads or w:1 writes; Jepsen's 2018 tests of MongoDB 3.6.4 found causal anomalies under sub-majority settings. Those historical tests do not establish a present-version defect. (medium confidence) [source]
Children
- Cross-service propagation of operationTime and clusterTime (frontier)
- afterClusterTime waits and replication apply lag (frontier)
- Durability versus freshness versus snapshot isolation (frontier)
Frontier under this node: Cross-service propagation of operationTime and clusterTime, Durability versus freshness versus snapshot isolation, afterClusterTime waits and replication apply lag