createCollectionForApplyOps should invariant that collections are not renamed in replication steady state

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Fixed
    • Priority: Major - P3
    • 4.3.3
    • Affects Version/s: None
    • Component/s: Storage
    • None
    • Fully Compatible
    • Execution Team 2019-12-30, Execution Team 2020-01-13, Execution Team 2019-12-30
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      createCollectionForApplyOps runs on secondaries and has functionality to temporarily rename a collection out of the way into a tmp collection, with the expectation that it will be renamed back again. This is for oplog replay when this scenario happens:

      1) createCollection(foo.bar) w/ UUID 1
      2) renameCollection(foo.bar to foo.baz) still w/ UUID 1
      3) createCollection(foo.bar) w/ UUID 2

      createCollectionForApplyOps will rename foo.bar w/ UUID 2 out of the way into a tmp collection when it sees 1) and create foo.bar w/ UUID 1, with the expectation that it will eventually see 3) and rename the tmp collection back.

      However, this code can leak bugs. When secondaries somehow have a collection that the primary doesn't, and the primary then creates the collection and the secondaries rename their original collection out of the way, orphaning it.

            Assignee:
            Daniel Ernst
            Reporter:
            Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: