Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-46022

Refactor handling of tasks scheduled to submit range deletions

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Sharding
    • Labels:
      None

      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.

        Attachments

          Activity

            People

            Assignee:
            backlog-server-sharding Backlog - Sharding Team
            Reporter:
            jack.mulrow Jack Mulrow
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: