SUMMARY

A reshardCollection operation on a cluster with at least two shards can potentially omit a collections catalog entry in a shards local catalog if a movePrimary operation had previously been issued on the same cluster. This impacts operations involving data migration that lookup the database cache namely movePrimary, reshardCollection, moveRange, and moveChunk.

The issue affects MongoDB versions since resharding was released in v5.0. The following versions contain fixes:
5.0.26, 6.0.15, 7.0.8, 7.3.2, 8.0.0

ISSUE DESCRIPTION AND IMPACT

When a movePrimary operation is followed by a reshardCollection operation,the new primary shard may not have a catalog entry for the resharded collection if it does not own any chunks under the new distribution.

This impacts operations involving data migration that rely on the database cache, such as movePrimary, reshardCollection, moveRange, and moveChunk. Consequently, listCollections command which looks up info from the primary shard will not show the resharded collection name.

Tools involving data cloning/backup, such as mongosync, mongodump, and mongoexport are also impacted and will miss the resharded collection.

Note that CRUD operations on the collection will continue to work correctly as the router will target reads and writes to the correct shards.

WORKAROUND

For users on affected versions, run the following command on the config server before executing reshardCollection:

db.adminCommand({ flushRouterConfig: "<db>" }), where <db> is the name of the database movePrimary ran on.

DIAGNOSIS & REMEDIATION

To diagnose and remediate the issue, you should:

1. Upgrade to one of the fixed versions mentioned above.
2. Run the script to confirm if you are impacted and address the underlying issue. Please review the README carefully before running the script. If you have any questions please open a support case or start a chat with the Atlas Support team.