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

Lazily initialize a record store's auto incrementing counter on deletes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0.20, 4.4.0-rc8, 4.2.9, 4.7.0
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.4, v4.2, v4.0
    • Sprint:
      Execution Team 2020-06-01, Execution Team 2020-06-15
    • Linked BF Score:
      14

      Description

      Apologies for summarizing the solution and not the problem.

      It's imperative that the update chain for a storage engine key goes in increasing timestamp order (with only a few explicit caveats). The lazy initializing of record ids only on inserts creates a scenario where a key can be reused, and in the case of the _mdb_catalog, can result in an update that can't be rolled back (intentional 0-timestamp value) sitting on top of an update that must be eligible for rollback. This sequence of updates "locks in" a non-majority committed update.

      The scenario:

      • Create collection A. Inserts into _mdb_catalog (initializing the counter to "1") with RecordId(1), Timestamp(10)
      • Drop collection A. Timestamp(20)
      • Rollback to 15
      • Replay drop collection A (No more records in the _mdb_catalog)
      • Create a non-replicated collection (e.g: `local.replset.initialsync`). Initialize the counter to "1", Insert Record(1), Timestamp(0)
      • Rollback to 15. The drop at timestamp 20 is "locked in". Collection A is missing

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              daniel.gottlieb Daniel Gottlieb
              Reporter:
              daniel.gottlieb Daniel Gottlieb
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: