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

Sharding collection with UnoptimizedSplitPolicy must not result in long writes unavailability

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 5.0.3, 5.1.0-rc0
    • Component/s: None
    • None
    • Sharding EMEA 2021-11-15

      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.

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

              Created:
              Updated:
              Resolved: