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

Race in sh.startBalancer()

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Sharding
    • Labels:
    • Operating System:
      ALL

      Description

      sh.startBalancer() calls updates the balancer document in config.settings, followed by watching for a change in the timestamp of the balancer lock. The sequence is:

      1. setBalancerState to true
      2. Get balancer lock document
      3. Extract the timestamp
      4. assert.soon (up to 30s by default) watching for the timestamp to change

      If the balancer manages to start and take the lock between #1 and #2, and starts doing a non-trivial chunk migration, then the timeout will occur. By contrast, if the balancer is slower the lock is taken after #2, then this will not happen, even if there is a non-trivial chunk migration.

      The impact of this is low, although the apparent failure of sh.startBalancer() (despite the balancer clearly working) is often confusing (and there are other reasons it can happen).

      Better would be to grab the lock document before enabling the balancer, and then pass it through to the (eventual) assert.soon.

      sh.stopBalancer() doesn't have this problem, because it waits for the balancer lock state to go to false.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: