-
Type: Task
-
Resolution: Fixed
-
Priority: Critical - P2
-
Affects Version/s: None
-
Component/s: None
-
None
-
Replication
-
Fully Compatible
-
v7.3
-
Repl 2024-01-22, Repl 2024-02-05, Repl 2024-02-19, Repl 2024-03-04
This ticket comes after the discussion in WT-12032 where it was found that the server sets the oldest ts after the stable ts by using the "force" field of the WT set_timestamp API. This is dangerous for the following reasons:
- A checkpoint happens when the ts are out of order (for instance because of background compaction), see
WT-12032. - Eviction happens when the ts are out of order which could result in data loss as update chains will pruned based on the oldest timestamp.
Goals of this ticket:
- Check if we can avoid setting the oldest timestamp greater than the stable timestamp in all cases.
- Check if we can use "force" less liberally than we currently are.
- has to be done before
-
SERVER-80123 Enable background compaction by default in appropriate test suites
- Closed
- is depended on by
-
SERVER-85406 Document more clearly the difference between initialDataTimestamp and oldestTimestamp
- Open
-
WT-12032 Investigate an out-of-order timestamp issue with the HS in MDB tests
- Closed
-
SERVER-80123 Enable background compaction by default in appropriate test suites
- Closed
- is related to
-
SERVER-85688 Set stable timestamp to end of each oplog batch during startup recovery for restore
- Closed
-
WT-12333 Provide mechanism to (re)set whether checkpoints should default to stable or unstable
- Backlog
-
WT-12345 Return an error when setting a timestamp to an older value
- Closed
- related to
-
SERVER-85688 Set stable timestamp to end of each oplog batch during startup recovery for restore
- Closed
-
SERVER-91841 Repaired nodes rejoining replica set can hit invariant
- Closed
-
SERVER-82686 Investigate if we need to explicitly take a stable checkpoint at the end of magic restore
- Closed
-
SERVER-85228 Disable auto compact temporarily
- Closed
-
SERVER-85722 Investigate assumption that mongo layer always tells storage engine when to take a checkpoint
- Closed
-
SERVER-86754 Investigate if magic restore can corrupt data due to oldest timestamp being greater than the stable timestamp
- Closed
-
SERVER-87983 Logical initial sync attempts to set the stable timestamp to 0 during setup
- Open