Optimize resharding when primary shard owns zero chunks for resharded collection

XMLWordPrintableJSON

    • Type: New Feature
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.1.0-rc0
    • Affects Version/s: None
    • Component/s: Sharding
    • Cluster Scalability
    • Fully Compatible
    • 200
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      The primary shard is always added as a recipient shard in a resharding operation. This is because commands like listCollections always target the primary shard even when the shard owns zero chunks for the sharded collection.

      The idea would be to have the primary shard skip cloning any collection data, any config.transactions entries, and any oplog entries. To put it another, the primary shard when it owns zero chunks would create the temporary resharding collection and then transition into kStrictConsistency. Some evaluation must still be done to ensure the resharding coordinator is capable of handling a recipient shard being in the kStrictConsistency state prior to all of the donor shards.

      This would have the ancillary benefit of addressing how approxDocumentsToCopy and approxBytesToCopy as non-zero values on the primary shard when it owns zero chunks.

              Assignee:
              Cheahuychou Mao
              Reporter:
              Max Hirschhorn
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: