[SERVER-25384] Create a config.migrations collection and a Scoped RAII object class to write to it for migrations Created: 01/Aug/16 Updated: 02/Sep/16 Resolved: 20/Aug/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.12 |
| 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 18 (08/05/16), Sharding 2016-08-29 | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
The balancer is going to write every active migrations to the config.migrations collection so that this collection can be used for migration recovery on balancer startup after a stepdown/crash. config.migrations should have fields to identify the specific chunk as well as a version and toShard field
This collection should have an index on (ns, min, max) so that duplicate migrations cannot be scheduled – this would fail anyway. The version field is necessary so that on recovery that balancer will not try to schedule a migration that managed to both succeed and be moved back to the original source shard. This can only happen if a v3.2 mongos is running and scheduling moveChunk commands directly to the shards rather than through the balancer – in v3.4, all moveChunks go through the balancer, i.e. a v3.4 mongos routes moveChunk commands to the balancer. ------------------------------------------------ Create a ScopedMigrationRequest RAII object class that will write to config.migrations on creation and destruction, to add and remove an entry, respectively. Create a static method that: The destructor does a local delete – don't need to worry about majority because if majority fails and we stepdown/crash, recovery will just safely check the migration. |
| Comments |
| Comment by Githook User [ 18/Aug/16 ] |
|
Author: {u'username': u'DiannaHohensee', u'name': u'Dianna Hohensee', u'email': u'dianna.hohensee@10gen.com'}Message: |
| Comment by Githook User [ 18/Aug/16 ] |
|
Author: {u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'kyle.suarez@mongodb.com'}Message: Revert " This reverts commit bb63fec164121c14f80a09ae80880c6629edac35. |
| Comment by Githook User [ 18/Aug/16 ] |
|
Author: {u'username': u'DiannaHohensee', u'name': u'Dianna Hohensee', u'email': u'dianna.hohensee@10gen.com'}Message: |
| Comment by Githook User [ 17/Aug/16 ] |
|
Author: {u'username': u'DiannaHohensee', u'name': u'Dianna Hohensee', u'email': u'dianna.hohensee@10gen.com'}Message: |
| Comment by Dianna Hohensee (Inactive) [ 02/Aug/16 ] |
|
True. Thanks! |
| Comment by Spencer Brody (Inactive) [ 02/Aug/16 ] |
|
Probably also need to include the collection epoch, in case the collection was dropped and re-created. |