[SERVER-46022] Refactor handling of tasks scheduled to submit range deletions Created: 06/Feb/20  Updated: 06/Dec/22  Resolved: 13/Apr/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Participants:

 Description   

After a successful migration, the donor shard will schedule a task to submit the moved away range for deletion in the MetadataManager. To enable migrations with waitForDelete=true, a future for submitting this deletion task is returned to the MigrationSourceManager and waited on to guarantee the task is in the MetadataManager before the MSM waits for it to remove that range (to avoid the race fromĀ SERVER-45917).

The logic for storing the future in the MSM is somewhat convoluted, and ideally wouldn't be necessary. This ticket is to refactor how ranges that have been scheduled to be submitted are handled to avoid this. One approach could be to have standalone "RangeDeletionService" type class that owns (UUID, range) pairs that have been submitted for deletion outside the MetadataManager, which the MSM can consult instead.


Generated at Thu Feb 08 05:10:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.