Catalog changes during setFCV can race with rename across DBs

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: 7.0.0, 8.0.0, 8.3.0-rc0, 8.2.0
    • Component/s: Catalog, Upgrade/Downgrade
    • None
    • Catalog and Routing
    • ALL
    • 2
    • 馃煢 Shard Catalog
    • None
    • None
    • None
    • None
    • None
    • None

      Background: During setFCV it is common to add/remove catalog fields by scanning the catalog by DB and running collMod on each collection (example 1, example 2, example 3).

      Problem: It's possible for rename across DBs to interleave like this:

      • Scan catalog of db1, run collMod over necessary collections
      • Rename db2.coll to db1.coll
      • Scan catalog of db2, run collMod over necessary collections

      In this case the renamed collection will dodge the scans and its metadata will not be changed by setFCV. This issue is very similar to SERVER-87931.

      Proposed solution: The catalog::forEachCollectionFromDb API should be changed to:

      1. Work with a single view of the catalog, not a different one by DB
      2. Consider that collections matching the predicate may appear while scanning the catalog. Note that it already tracks renames by UUID but this does not work for rename across DBs which creates a clone with a new UUID. It must refresh the catalog until it observes a catalog instance where no collections match the predicate.

      A reproducer is attached (for recordIdsReplicated).

            Assignee:
            Unassigned
            Reporter:
            Joan Bruguera Mic贸
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: