[SERVER-51291] Increment shard version when changing original or temporary resharding collection Created: 01/Oct/20 Updated: 29/Oct/23 Resolved: 03/Nov/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Blake Oler |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-234-M1, PM-234-T-lifecycle | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Sprint: | Sharding 2020-10-19, Sharding 2020-11-02, Sharding 2020-11-16 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 40 | ||||||||||||||||||||
| Description |
|
Every time the coordinator wants a set of shards (donor/recipient) to be aware of changes, it should:
So that every shard will have a "shard version" of [currentMaxVersion + 1], where a "shard version" is the maximum chunk version existing on that shard for a collection. This can be done in the update methods in the ReshardingCoordinatorService |
| Comments |
| Comment by Githook User [ 05/Nov/20 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: |
| Comment by Githook User [ 03/Nov/20 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: |
| Comment by Githook User [ 03/Nov/20 ] |
|
Author: {'name': 'sviatlana_zuiko', 'email': 'sviatlana.zuiko@mongodb.com'}Message: Revert " This reverts commit 411dab1fa8060e48e11bf67b396be3ff24b94d3b. |
| Comment by Githook User [ 03/Nov/20 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: |
| Comment by Kaloian Manassiev [ 02/Oct/20 ] |
|
Another thing that we were brainstorming of doing some time ago is to add another "timestamp" to the config.collection entry to indicate that something has changed, which is not per-shard. This would be a new component to the shardVersion, which is being gossiped. This would obviate the need to modify one chunk per-shard to emulate that behaviour, however it might take a lot more time to implement that what you have proposed here. I think you should proceed with the plan that you have outlined here, Haley, but please abstract that part which updates one chunk per shard in order to trigger a refresh into some common utility, so we can replace it if we decide to go that way. FYI sergi.mateo-bellido (it is related to the shardVersion/epoch work that you are doing) and tommaso.tocci. |