-
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:
- Work with a single view of the catalog, not a different one by DB
- 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).
- is related to
-
SERVER-87931 MovePrimary + FCV upgrade / downgrade race may dodge FCV cleanup & checks
-
- Closed
-
- related to
-
SERVER-117883 convertToCapped may fail during downgrade due to collections with recordIdsReplicated option
-
- In Progress
-
-
SERVER-119136 Validate the schema of the shard catalog in testing
-
- Needs Scheduling
-