Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-58082

Fail resharding operation if allowMigrations has already been set to false

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.0.4, 5.1.0-rc0
    • Affects Version/s: None
    • Component/s: Sharding
    • Labels:
    • Fully Compatible
    • v5.0
    • Sharding 2021-07-12, Sharding 2021-07-26, Sharding 2021-08-09, Sharding 2021-08-23
    • 1

      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(
              return BSON("$set" << BSON(CollectionType::kReshardingFieldsFieldName
                                          << originalEntryReshardingFields.toBSON()
                                          << CollectionType::kUpdatedAtFieldName
                                          << opCtx->getServiceContext()->getPreciseClockSource()->now()
                                          << CollectionType::kAllowMigrationsFieldName << false));

            randolph@mongodb.com Randolph Tan
            max.hirschhorn@mongodb.com Max Hirschhorn
            0 Vote for this issue
            2 Start watching this issue