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

Avoid taking strong lock on collection as part of donor shards in resharding choosing minFetchTimestamp

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Do
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • None
    • Sharding NYC
    • 5

      Donor shards taking a collection S lock in generateMinFetchTimestamp() on the collection being resharded is a heavy-handed way to wait for all earlier writes on the collection to have finished. Despite the intention to only block writes, in the absense of lock-free reads, the collection S lock would lead to readers also being block. This is because a collection IX lock request which queues up after the S lock request will cause any subsequent collection IS lock requests to also queue.

      Donor shards must guarantee after the minFetchTimestamp value that all oplog entries for writes on the collection being resharding contain a "destinedRecipient" field. An alternative approach would be (1) to wait for any prepared transactions to commit or abort and (2) to throw a WriteConflictException for any other write on the collection being resharded that started before the minFetchTimestamp value.

            Assignee:
            backlog-server-sharding-nyc [DO NOT USE] Backlog - Sharding NYC
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: