[SERVER-58082] Fail resharding operation if allowMigrations has already been set to false Created: 24/Jun/21  Updated: 29/Oct/23  Resolved: 20/Aug/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 5.0.4, 5.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Randolph Tan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-50027 Freeze migrations on original sharded... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v5.0
Sprint: Sharding 2021-07-12, Sharding 2021-07-26, Sharding 2021-08-09, Sharding 2021-08-23
Participants:
Story Points: 1

 Description   

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.

241
switch (nextState) {
242
    case CoordinatorStateEnum::kInitializing: {
243
        // Append 'reshardingFields' to the config.collections entry for the original nss
244
        TypeCollectionReshardingFields originalEntryReshardingFields(
245
            coordinatorDoc.getReshardingUUID());
246
        originalEntryReshardingFields.setState(coordinatorDoc.getState());
247
 
248
        return BSON("$set" << BSON(CollectionType::kReshardingFieldsFieldName
249
                                    << originalEntryReshardingFields.toBSON()
250
                                    << CollectionType::kUpdatedAtFieldName
251
                                    << opCtx->getServiceContext()->getPreciseClockSource()->now()
252
                                    << CollectionType::kAllowMigrationsFieldName << false));
253
    }



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 22/Sep/21 ]

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-58082 Fail resharding operation if allowMigrations has already been set to false

(cherry picked from commit 1bf0b9e307160213b47a1b996ea2abb68be1169f)
Branch: v5.0
https://github.com/mongodb/mongo/commit/52ed2e2be494a30ed067cc9006df4d309f5692fe

Comment by Githook User [ 20/Aug/21 ]

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-58082 Fail resharding operation if allowMigrations has already been set to false
Branch: master
https://github.com/mongodb/mongo/commit/1bf0b9e307160213b47a1b996ea2abb68be1169f

Comment by Max Hirschhorn [ 25/Jun/21 ]

kaloian.manassiev, I don't believe this is a problem in the code today for exactly the reason you raised about the DDL coordinators. I filed this ticket to future-proof things. To me, setting allowMigrations to false should be a compare-and-swap kind of operation and resharding doesn't currently do the compare portion.

Comment by Kaloian Manassiev [ 25/Jun/21 ]

Currently only DDL operations set the allowMigrations field. Since only one DDL can run per database currently, it shouldn't be possible that resharding finds it set (resharding has a fake DDL coordinator on the primary). Did you find this through a BF by any chance?

Generated at Thu Feb 08 05:43:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.