-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.2.18, 3.4.10, 3.6.0, 3.7.1
-
Component/s: Sharding
-
Sharding
-
ALL
-
27
If a movePrimary command was able to clone the database but failed to complete (for example, because it stepped down), it will leave the database and the other collections in the original shard. Attempting to call the command again will do nothing because the primary database is now officially moved to the another shard, leaving the unsharded collections orphaned on the old primary shard.
There's also another variant where it fails after it successfully clones, but before it updates config.databases. In this scenario, attempting to retry to command will result in the command attempting to call clone again, but fail with collection already exits.
- is related to
-
SERVER-31398 _configsvrMovePrimary retries fail if clone from old primary completed in a previous attempt
- Closed
- related to
-
SERVER-46425 Consider increasing wtimeout for cloneCatalogData or no timeout
- Backlog
-
SERVER-46424 _cloneCatalogData remote call is labeled as idempotent and retryable although it isn't
- Closed