The allowMigrations field was initially added to the config.collections entry as part of SERVER-50027 to prevent chunk migrations from successfully committing during a resharding operation. It is now also used by DDL operations for a similar reason. DDL operations such as dropping a database, dropping a collection, or renaming a collection are mutually exclusive with resharding due to the distributed lock being held. However, it would be safer if the resharding operation failed if allowMigrations has already been set to false. The idea is that a resharding operation should only proceed to shuffle data around in the sharded cluster if it was the one which set allowMigrations to false. Similarly, the resharding coordinator must not unset the allowMigrations field if the resharding operation aborts due to allowMigrations already being set to false.
switch (nextState) { case CoordinatorStateEnum::kInitializing: { // Append 'reshardingFields' to the config.collections entry for the original nss TypeCollectionReshardingFields originalEntryReshardingFields( coordinatorDoc.getReshardingUUID()); originalEntryReshardingFields.setState(coordinatorDoc.getState()); return BSON("$set" << BSON(CollectionType::kReshardingFieldsFieldName << originalEntryReshardingFields.toBSON() << CollectionType::kUpdatedAtFieldName << opCtx->getServiceContext()->getPreciseClockSource()->now() << CollectionType::kAllowMigrationsFieldName << false)); }
- is related to
-
SERVER-50027 Freeze migrations on original sharded collection while the resharding operation is in progress
- Closed