-
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
-
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.
- 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
-