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

Race in migration source registration and capturing writes for xferMods for deletes

    • Sharding NYC
    • Fully Compatible
    • ALL
    • v7.1, v7.0, v6.0, v5.0, v4.4
    • 108

      The migration cloner installs itself to the CollectionShardingRuntime while holding the csr lock in exclusive mode. The op observers take the csr lock in shared mode to extract the cloner and capture the write. However, it completely skips this if it cannot find the cloner. Therefore the following scenario is possible:

      1. Doc A is inserted.
      2. ThreadA starts a wuow and performs delete on doc A.
      3. Delete tries to check for cloner and finds out that it is not attached to the csr, so it decides not to capture the write.
      4. Migration starts and installs cloner to csr.
      5. Migration clone scans through the collection, clones doc A and gets sent to the recipient shard.
      6. ThreadA commits wuow.
      7. Migration finishes and write done by threadA is not transfered.

            Assignee:
            randolph@mongodb.com Randolph Tan
            Reporter:
            randolph@mongodb.com Randolph Tan
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'slack.nextup.jira:slack-integration-plus'. Please contact your Jira administrators.