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

Reevaluate whether a forced refresh is necessary in the commit phase of the MigrationSourceManager

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Won't Fix
    • Icon: Major - P3 Major - P3
    • None
    • 3.7.6
    • Sharding
    • None
    • Sharding

    Description

      Currently, the MigrationSourceManager forces a fresh of sharding metadata after a commit has been attempted, no matter whether the commit succeeds or fails. A refresh is costly and shouldn't be necessary every time.

      Instead, we should do the following:

      1. After a commit attempt (both success AND failure), clear the shard version on the source shard.
      2. On a successful commit, return without refreshing.
      3. On a failed commit, return the commit status.

      That assures the following behavior:

      If the commit fails, then when attempting to access this chunk, the source shard will refresh from the config server and reassume ownership for that chunk.

      If the commit succeeds, then when attempting to access this chunk, the source shard will refresh from the config server and find out it's not the owner of the chunk. The mongos will then reroute access to the destination shard.

      Attachments

        Activity

          People

            backlog-server-sharding [DO NOT USE] Backlog - Sharding Team
            blake.oler@mongodb.com Blake Oler
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: