[SERVER-24352] configs initialize sharding awareness on sharding-unaware shards on transition to primary Created: 01/Jun/16 Updated: 13/Aug/16 Resolved: 27/Jul/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.3.6 |
| Fix Version/s: | 3.3.11 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (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 15 (06/03/16), Sharding 16 (06/24/16), Sharding 17 (07/15/16), Sharding 18 (08/05/16) | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Add a class that can run a BackgroundJob on the config servers to initialize sharding awareness on any shards in config.shards that are not marked as sharding aware (as represented by a flag field in config.shards). The BackgroundJob can be kicked off on transition to primary or by an OpObserver watching for inserts to config.shards. While the cluster upgrade is in progress:
|
| Comments |
| Comment by Githook User [ 27/Jul/16 ] |
|
Author: {u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 01/Jun/16 ] |
|
Sounds good, maybe a method can be added to CatalogManager to do the check in config.shards and that uses the executorForAddShard to do the shardIdentity insert. |
| Comment by Spencer Brody (Inactive) [ 01/Jun/16 ] |
|
I don't think this is done as a literal BackgroundJob subclass. I think you just have a function that is called during config server transition to primary, and the OpObserver just schedules that function to run in a TaskExecutor. |
| Comment by Esha Maharishi (Inactive) [ 01/Jun/16 ] |
|
Resolution for the TODO: we decided that the insert of the shardIdentity document should not fail on the shard, and that the shard can simply reject sharding requests until it is restarted with --shardsvr. This is to allow for manual modification (e.g., delete and re-insert) of the shardIdentity document during things like backup-restore. |
| Comment by Esha Maharishi (Inactive) [ 01/Jun/16 ] |
|
renctan, spencer, please confirm if the behavior in the TODO in the last bullet point is what we want? |