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

Submit range deletion tasks upon sharded collection rename

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.9.0
    • Fix Version/s: 4.9.0
    • Component/s: Sharding
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL

      Description

      On SERVER-54132 we realized that the orphans check at the end of the tests was not running due to this check for {dropped: false}. As this was fixed, it was uncovered that rename_sharded.js had orphans left around. 

      It happens when the rename runs after a move chunk that has not yet executed the range deletion. Temporarily, we changed the moveChunk to {waitForDelete: true} in the test.

      Chosen approach (executed locally on each shard):

      Precondition: moveChunks are blocked

      • Get a list of source collection's persistent range deletion tasks
      • Rename source collection to target
      • Update _id (random) and nss (target) in the entries of the previously initialized list
      • Persist range deletions tasks for the target collection

      This is safe because:

      • The SubmitRangeDeletionHandler observer will submit the new tasks to the range deleter
      • Old tasks referring the source collection will be discarded by the range deleter because the namespace was dropped

        Attachments

          Activity

            People

            Assignee:
            pierlauro.sciarelli Pierlauro Sciarelli
            Reporter:
            jordi.serra-torrens Jordi Serra Torrens
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: