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

Sharding a very large collection can result in a long stall of writes against this collection

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Sprint:
      Sharding 2019-04-08, Sharding 2019-04-22, Sharding 2019-05-06, Sharding 2019-05-20

      Description

      Starting in 4.0.6, with the initial collection splits (when sharding a collection) being driven by the database primary, the shard takes the critical section for the collection, which blocks writes. If the collection is not empty, then the shard will call splitVector in order to determine the initial split points for the collection.

      For very large collections, the splitVector call can take very long time, during which the collection will be unavailable for writes.

      In order to improve this, we should rearrange the code so that the splitVector operation is run outside of the critical section.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: