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

Implement recovery of a shard's `shardVersion` before it is allowed to perform version checking

    XMLWordPrintableJSON

Details

    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.7.0
    • Sharding
    • Fully Compatible
    • Sharding 2020-05-18, Sharding 2020-06-01, Sharding 2020-06-15
    • 38

    Description

      The sharding migration commit protocol does not perform a proper 2-phase commit in order to have the minimum possible latency impact in the steady state. Because of this, the following theoretical sequence of events is possible:

      • The current primary of a shard is just about to commit migration against the config server
      • A new primary is elected, which refreshes from the config server before the commit from the previous primary has reached it
      • The new primary sees old shardVersion (and as a result also filtering metadata) and incorrectly accepts writes which are supposed to go to a different shard

      The RangeDeleter project implemented a command to bump a chunk's shard version and also added a check for chunk version equality as part of the migration commit. We should package that logic into an asynchronous task and make sure that forceFilteringMetadataRefresh executes that recovery logic before accepting the shardVersion returned from the config server.

      Attachments

        Issue Links

          causes

          Bug - A problem which impairs or prevents the functions of the product. SERVER-48883 Range deletion recovery can invalidate migration recovery on step up

          • Major - P3 - Major loss of function.
          • Closed
          depends on

          Task - A task that needs to be done. SERVER-47974 Introduce ScopedShardVersionCriticalSection class

          • Major - P3 - Major loss of function.
          • Closed

          Task - A task that needs to be done. SERVER-47975 Optimize ScopedShardVersionCriticalSection in order to avoid convoy on SSV after a shardVersion change

          • Major - P3 - Major loss of function.
          • Closed
          is depended on by

          Bug - A problem which impairs or prevents the functions of the product. SERVER-48589 Ensure migration recovery is completed before to run a new chunk migration

          • Major - P3 - Major loss of function.
          • Closed

          Task - A task that needs to be done. SERVER-45983 Perform the shardVersion recovery and refresh on a separate thread from that of the user request

          • Major - P3 - Major loss of function.
          • Closed

          Task - A task that needs to be done. SERVER-47982 Change the shard version update procedure of the migration source manager

          • Major - P3 - Major loss of function.
          • Closed

          Task - A task that needs to be done. SERVER-47986 Introduce a thread to complete the shard version recovery after step-up

          • Major - P3 - Major loss of function.
          • Closed
          is related to

          Task - A task that needs to be done. SERVER-47986 Introduce a thread to complete the shard version recovery after step-up

          • Major - P3 - Major loss of function.
          • Closed

          Activity

            People

              tommaso.tocci@mongodb.com Tommaso Tocci
              tommaso.tocci@mongodb.com Tommaso Tocci
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: