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

Sharding collection with UnoptimizedSplitPolicy must not result in long writes unavailability

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Duplicate
    • 5.0.3, 5.1.0-rc0
    • None
    • None
    • None
    • Sharding EMEA 2021-11-15

    Description

      Starting from v5.0, sharding a non-empty collection results in writes being blocked for a time proportional to the number of documents in the collection. As a result, sharding a collection containing a lot of documents means being just able to read it for a very long time.

       

      The relevant difference between v4.4 and v5.0 is the context in which selectChunkSplitPoints is called in UnoptimizedSplitPolicy::createFirstChunks: in the older version it doesn't happen under the critical section while in the new one it happens after it gets acquired. The invoked splitVector command is quite slow because it scans the whole index to search for the initial split points.

      Attachments

        Issue Links

          Activity

            People

              marcos.grillo@mongodb.com Marcos José Grillo Ramirez
              pierlauro.sciarelli@mongodb.com Pierlauro Sciarelli
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: