[SERVER-57587] Avoid scheduling more range deletion tasks for same range during rename Created: 09/Jun/21 Updated: 29/Oct/23 Resolved: 10/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 5.1.0, 5.0.0-rc1 |
| Fix Version/s: | 5.0.0-rc2, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | Pierlauro Sciarelli |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-1965-Cleanup | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Backport Requested: |
v5.0
|
||||
| Sprint: | Sharding EMEA 2021-06-14 | ||||
| Participants: | |||||
| Description |
|
Currently, the "idempotency" of restoreRangeDeletionTasksForRename is achieved by deleting previously "renamed" range deletion tasks and reschedule them with new migration ids. By doing so, the persistent state is clean but duplicate tasks are not unscheduled from the migration util executor. A better strategy would be to assign migrations id to snapshotted range deletions at an early stage and afterwards simply check if the task has been already scheduled for the target collection. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 11/Jun/21 ] |
|
Author: {'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}Message: |
| Comment by Githook User [ 10/Jun/21 ] |
|
Author: {'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}Message: |