-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding
-
ALL
-
26
If the CSRS primary steps down while executing _configsvrMovePrimary after having told the toShard to clone the non-sharded collections from the old primary shard, the clone will still complete because the shards won't know the command was interrupted, but mongos will receive a retryable error and retry _configsvrMovePrimary when the next primary steps up, because it uses RetryPolicy::kIdempotent. When the new primary sends the clone command to the toShard again, the clone will fail, because the namespaces to be cloned will already exist on the toShard, causing the whole command to fail (unless there weren't any unsharded collections).
- is related to
-
SERVER-31526 Replace use of ScopedDbConnection in _configsvrMovePrimary with Shard because it fails clone without retrying NotMaster errors from a shard
- Closed
- related to
-
SERVER-32142 `movePrimary` can leave orphaned data when it aborts after cloning
- Closed