[SERVER-83791] Rename collection should track collections in fcv upgrade Created: 01/Dec/23  Updated: 07/Feb/24

Status: Open
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Marcos José Grillo Ramirez Assignee: Backlog - Catalog and Routing
Resolution: Unresolved Votes: 0
Labels: PM-3364-Milestone-5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-79159 Track unsharded collections on upgrade Open
Assigned Teams:
Catalog and Routing
Participants:

 Description   

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.


Generated at Thu Feb 08 06:53:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.