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

      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: