[SERVER-25905] In transition to config primary, drop all distlocks, and reacquire balancer distlocks Created: 31/Aug/16  Updated: 19/Nov/16  Resolved: 21/Sep/16

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 3.3.14

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-26013 Add means to the DistLockManager to r... Closed
Related
related to SERVER-26222 MigrationManager::_abandonActiveMigra... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2016-09-19, Sharding 2016-10-10
Participants:

 Description   

In drain mode, drop all config locks:

// Free any leftover locks from previous instantiations
auto distLockManager = Grid::get(txn)->catalogClient(txn)->getDistLockManager();
distLockManager->unlockAll(txn, distLockManager->getProcessID());

and reacquire distlocks for all the the collections that have migration documents in config.migrations. Lock the distlocks with clusterId so that the balancer code can overtake the locks (because it uses clusterId as a lock session ID).

----------------

This is to cover the case – which 'technically' should never happen – where the config.migrations collection doesn't match with all the config.locks docs held by the balancer when a new primary is elected.



 Comments   
Comment by Githook User [ 21/Sep/16 ]

Author:

{u'username': u'DiannaHohensee', u'name': u'Dianna Hohensee', u'email': u'dianna.hohensee@10gen.com'}

Message: SERVER-25905 Release all config held distlocks and reacquire balancer distlocks in drain mode on config step up to primary
Branch: master
https://github.com/mongodb/mongo/commit/31c4b8293f2607f38cacf132d8c755e1e04784fb

Comment by Githook User [ 15/Sep/16 ]

Author:

{u'username': u'DiannaHohensee', u'name': u'Dianna Hohensee', u'email': u'dianna.hohensee@10gen.com'}

Message: Revert "SERVER-25905 Release all config held distlocks and reacquire balancer distlocks in drain mode on config step up to primary"

This reverts commit f8212b6b37bea1bead354df86e8485761a519339.
Branch: master
https://github.com/mongodb/mongo/commit/c17b1c84bc6c18a47e4215d6b6238ae12d6854fc

Comment by Githook User [ 15/Sep/16 ]

Author:

{u'username': u'DiannaHohensee', u'name': u'Dianna Hohensee', u'email': u'dianna.hohensee@10gen.com'}

Message: SERVER-25905 Release all config held distlocks and reacquire balancer distlocks in drain mode on config step up to primary
Branch: master
https://github.com/mongodb/mongo/commit/f8212b6b37bea1bead354df86e8485761a519339

Comment by Dianna Hohensee (Inactive) [ 31/Aug/16 ]

We could just create the CollectionMigrationsState when we go in to reacquire the locks in drain mode. Then it looks like there are no checks on CollectionMigrationsState's 'migrations' list until cleaning up after a migration, at which point it has one migration in it and it should be okay.

How to handle MigrationManager::finishRecovery failures would have to change a bit. Probably just go through the existing CollectionMigrationsStates and release all the locks via that.

Comment by Dianna Hohensee (Inactive) [ 31/Aug/16 ]

Before doing this, it should be explored whether we could recreate the distlocks and store them in the MigrationManager, without using clusterId as a lock sessionId but rather a randomly generated OID for each, perhaps by creating the CollectionMigrationsState objects. See how invasive the change would be to MigrationManager, and whether it's worth doing.

Removing the clusterId as session ID would get rid of the necessity of this distlock catalog+manager commit, https://github.com/mongodb/mongo/commit/6b5fd115d38582d8b349a5aad2c29867e69dc758#diff-5b3bc744a1b56a2b2b44d69177922ef8 – it could be reverted.

Generated at Thu Feb 08 04:10:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.