Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Critical - P2
Fix Version/s: 8.0.0-rc0
Affects Version/s: None
Component/s: None
Labels:
None

Assigned Teams:

Replication
Backwards Compatibility:
Fully Compatible
Backport Requested:

v7.3
Sprint:
Repl 2024-01-22, Repl 2024-02-05, Repl 2024-02-19, Repl 2024-03-04
Confidence Status:
None
Work Order:
0

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name:
None
Goal Link:
None

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

Closed

(2 is related to, 7 related to)

Assignee:: Xuerui Fa
Reporter:: Etienne Petrel
Participants:: Etienne Petrel, Githook User, Xuerui Fa
Votes:: 0 Vote for this issue
Watchers:: 27 Start watching this issue

Created:: Jan 09 2024 10:24:26 PM UTC
Updated:: Jun 25 2024 09:43:22 PM UTC
Resolved:: Feb 21 2024 04:54:56 PM UTC
Confidence Status Last Update:: 11/Jan/24 9:30 PM

Details

Description

Attachments

Issue Links

Activity

People

Dates