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

Implement support for legacy and new migration protocol -- shard versus balancer holding the distributed lock



    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 3.3.9
    • Sharding
    • None
    • Fully Compatible
    • Sharding 15 (06/03/16), Sharding 16 (06/24/16)


      This task is for the changes which need to be made to the donor shard's migration manager so that it supports both the legacy migration protocol (shard acquires the distlock) and the new protocol where the CSRS primary holds the distributed lock.

      Implementation (high level):

      Config balancer:
      The balancer will always first take the distributed lock for the collection in which it's about to move a chunk. A protocol flag will be added to the moveChunk command. This flag will be ignored if the shard receiving it is old – it won't know to parse for it. In the case of an old shard, the shard will attempt to take the distributed lock as usual and get a LockBusy – or something – error, which will be returned to the balancer. The balancer will then interpret this response as the shard using the old protocol and release the distributed lock and call moveChunk again, and this time the shard will successfully take the distributed lock as usual.

      The shard will parse the moveChunk command for the new protocol flag. If it finds it, then it will not attempt to take the distributed lock for the collection. Instead the shard should check that the balancer possesses the distributed lock for the collection.

      Add testing if any new code does not get checked by existing testing. Probably need to make a multi-version test.


        Issue Links



              dianna.hohensee@mongodb.com Dianna Hohensee
              kaloian.manassiev@mongodb.com Kaloian Manassiev
              0 Vote for this issue
              5 Start watching this issue