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

Rollback via refetch can result in out of order timestamps

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Backlog
    • Major - P3
    • Resolution: Unresolved
    • None
    • None
    • Replication, Storage
    • None
    • Replication
    • ALL

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              backlog-server-repl Backlog - Replication Team
              daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated: