-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Catalog and Routing
Suppose we're upgrading a cluster from 7.0 or 7.3 to 8.0. During the process, the collections present in the shard's local catalog will be registered by launching a CreateCollectionCoordinator as described in the project design, however, if a rename interleaves the process, it might end up leaving a collection in a shard that is not registerd in the config server. The situation is the following:
- In 7.0 (or 7.3) we create db.coll1 and db.coll2
- We upgrade the binaries, and run setFeatureCompatibilityVersion: '8.0', which launches CreateCollectionCoordinators for db.coll1 and db.coll2
- After registering db.coll1 a rename from db.coll1 to db.coll2 sneaks in, removing the metadata of db.coll1, and leaving just db.coll2 in the local catalog.
- The coordinator finds that there is no db.coll2 so it becomes a no-op
This situation can be seen in the attached patch, considering the changes of SERVER-79159. We should change the rename collection to also register the destination shard if we're in the upgrading process.
- is related to
-
SERVER-79159 Track unsharded collections on upgrade
- Open