-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
Fully Compatible
-
ALL
-
v9.0
-
ClusterScalability 14Sep-28Sep
-
0
-
None
-
None
-
None
-
None
-
None
-
None
-
None
After magic restore aborts an in-progress resharding, the rebuilt ReshardCollectionCoordinator on the db-primary shard re-sends _configsvrReshardCollection and starts a fresh resharding (SERVER-131275). The new op creates resharding collections that fail the post-restore dbhash check (BF-44897).
Apply the same workaround as SERVER-131413: pass a user-supplied reshardingUUID to reshardCollection in magic_restore_pit_resharding.js and magic_restore_non_pit_resharding.js, with a TODO(SERVER-131275) to remove it.
- is related to
-
SERVER-131275 ReshardCollectionCoordinator can incorrectly restart a reshardingCoordinator after a failover
-
- Backlog
-
-
SERVER-131413 Pass UUID for all reshardings in magic restore quiesce testing
-
- Closed
-