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

Remove the shardVersion check when entering the critical section.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.4.15, 3.5.4
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v3.4
    • Sprint:
      Sharding 2017-03-06
    • Case:
    • Linked BF Score:
      0

      Description

      We check here that the shardVersion we began the migration with is still the shardVersion. This seems like an unnecessary check now, since shards no longer hold distributed locks.

      We're running into a race condition when a shard is the recipient of a chunk and then the donor of a chunk in quick succession. This is the scenario:

      • There a migration from shard Y to shard X.
      • We release destination shard X before the donor shard Y commits the migration to the config server.
      • Shard X starts acting as a donor shard in a new migration, still before shard Y commits the previous migration.
      • Donor shard X reloads the chunk metadata at the start of the new migration, setting the MigrationSourceManager::_collectionMetadata with that newly loaded chunk metadata.
      • Shard Y finally finishes the commit.
      • Shard X attempts to enter the critical section, checks MigrationSourceManager::_collectionMetadata's shardVersion still matches the shard's current chunk metadata, sees that they're different and fails.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: