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

Two-phase dropDatabase may not replicate all collection drops before the database drop.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.6.0
    • Fix Version/s: 3.6.3, 3.7.1
    • Component/s: Replication
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Repl 2018-01-15

      Description

      The first phase of dropDatabase (for replicate sets) in 3.6 is to individually drop each collection (drop in this first phase is a misnomer for rename). When those "drops" are majority confirmed, the primary replicates a dropDatabase oplog entry.

      However the loop uses an iterator over the _collections map and db->dropCollectionEvenIfSystem will perform a rename. This rename erases the entry followed by adding it back under a different name. The expectation of the for-each collection loop is that all collections will be observed. The erase/add of the underlying map breaks that requirement.

      This can result in some collections not being dropped on the primary nor the secondary in the first part of dropping a database. I do believe the second phase of dropping a database that's associated with the dropDatabase oplog entry will be renamed and/or dropped on both the primary and secondary.

      One possible fix is to copy the values from the map to iterate over instead.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              benety.goh Benety Goh
              Reporter:
              daniel.gottlieb Daniel Gottlieb
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: