[SERVER-51660] Propagate resharding fields through the enqueued metadata combination algorithm Created: 15/Oct/20 Updated: 29/Oct/23 Resolved: 15/Oct/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: | Blake Oler | Assignee: | Janna Golden |
| 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 | ||||||||
| Participants: | |||||||||
| Description |
|
If we have multiple CollAndChunkTasks enqueued to be persisted to disk, we will lose the reshardingFields field when iterating through the tasks. We're assuming with this ticket that the iteration will be from oldest to newest, so we can always prefer the next task's ReshardingFieds struct when iterating. This ticket's implementer will need to verify that assumption with renctan. If the above assumption isn't correct, we can write a ReshardingFields comparator. It's safe just to compare based on state, because the coordinator should never modify the ReshardingFields for a collection when not also modifying state. |
| Comments |
| Comment by Githook User [ 15/Oct/20 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |