[SERVER-65538] Serialize scheduling of new range deletions behind range deletion to be resumed Created: 13/Apr/22 Updated: 27/Oct/23 Resolved: 14/Sep/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 6.0.0-rc0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
However, since the scheduling is done asynchronously, it may happen (even if really improbable) that a migration succeeds and schedules a range deletion before the one being resumed. Purpose of this ticket is to ensure that also the scheduling of new range deletions serializes behind the on getting resumed. |
| Comments |
| Comment by Pierlauro Sciarelli [ 14/Sep/22 ] |
|
Closing as "works as designed" because the new range deleter service provides such serialization. Only versions pre-v6.2 are affected, and if the race happens it's not a big deal. |