Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-48603

Rollback via refetch can result in out of order timestamps

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Replication, Storage
    • Labels:
      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.

            Assignee:
            kishore.devireddy@mongodb.com Kishore Devireddy
            Reporter:
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: