-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Storage
-
None
-
Replication
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
It can be convenient to allow MDB nodes to allow inserts into the oplog (and is even necessary for some current restore procedures). But oplog entries being inserted with a bad (stale) timestamp trip this fassert.
The fassert is important for correctness of the typical writes replication performs against the oplog (that are still on behalf of a user operation). But there is hopefully a path for validating these timestamps.
Perhaps a strict validation that an oplog entry's ts field is larger than the current top of oplog? With an exception for an explicit `ts: Timestamp(0, 0)` as I expect the server to be choosing TopOfOplog + 1.
- duplicates
-
SERVER-48637 error:WiredTiger error (22) and Fatal assertion 39001
-
- Closed
-
- is related to
-
SERVER-67790 [4.2] Running with enableMajorityReadConcern=false can commit behind the oldest/stable timestamp
-
- Closed
-
-
-
- Closed
-