[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: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Sharding 2016-09-19, Sharding 2016-10-10 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
In drain mode, drop all config locks:
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: |
| 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 " This reverts commit f8212b6b37bea1bead354df86e8485761a519339. |
| 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: |
| 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. |