-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 7.0.0, 8.0.0, 8.2.0, 9.0.0-rc0, 8.3.0, 9.1.0-rc0
-
Component/s: None
-
Replication
-
Repl 2026-08-03, Repl 2026-08-17, Repl 2026-08-31, Repl 2026-09-14
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Currently a node that just stepped up as writable primary can fail {readConcern: {level: "snapshot"}} reads with a SnapshotUnavailable: "No committed OpTime for snapshot read" until it can manage to advance the committed snapshot via the JournalFlusher.
This behavior is surprising considering majority reads and snapshot reads with atClusterTime instead wait until the read concern can be satisfied.
We should consider also waiting in this case so a failover is more transparent to users.
- is related to
-
SERVER-133161 After initial sync completes, a node can leave STARTUP2 already at tip (its applied optime matches the set) with a valid commit point, while {_currentCommittedSnapshot} is still unset.
-
- Closed
-
-
SERVER-89619 Avoid serving stale data with primary read preference + majority read concern on old primary during an unplanned election
-
- Blocked
-
-
SERVER-18584 A primary should write 'n' op when elected
-
- Closed
-
- related to
-
SERVER-132175 checkMetadataConsistency may return SnapshotUnavailable from failed internal snapshot read
-
- Closed
-
-
SERVER-47572 Snapshot reads without atClusterTime should read from majority committed snapshot
-
- Closed
-