-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
None
-
Replication
-
ALL
-
Repl 2024-06-10
This is a hypothetical that I'm documenting for investigation. The idea was inspired by suganthi.mani's discovery in SERVER-48518. Unlike SERVER-48518, this out of order timestamp condition is only problematic when WT is running with durable history.
Consider the following sequence where a primary accepts some writes, rolls them back, and then as a secondary replicates writes that use the same key-space.
- As primary
- Insert {_id: 1, doc: "A"} @ TS 20 RecordId(5)
- Delete {_id: 1, doc: "A"} @ TS 30
- Stepdown, perform Rollback via refetch to back to TS 10
- Rolls back delete – refetch {_id: 1} from sync source. The document does not exist – do nothing
- Rolls back insert – the {_id: 1} document doesn't exist in the index – do nothing
- Become secondary
- Replicate Insert {_id: 1, doc: "B"} @ TS 15
RecordId(5)RecordId(6)
In this state, there are two update chains with out of order timestamps:
RecordStore: RecordId(5) V3(15) -> V2(30) -> V1(20) See comments
Index: KeyString(1) V3(15) -> V2(30) -> V1(20)
Note the out of order updates in the RecordStore case are not alleviated by SERVER-48453 as this problem would still exist without lazy-initialization.
- is duplicated by
-
SERVER-84788 Remove RollbackViaRefetch method
- Closed
- is related to
-
SERVER-48453 Lazily initialize a record store's auto incrementing counter on deletes
- Closed
-
WT-6388 Fix-up out-of-order updates in the history store
- Closed
- related to
-
SERVER-48518 Rollback via refetch (EMRC = false) can make readers to see the rolled back data even after the rollback node catches up to primary.
- Closed