Make resharding account for the number of recipients without chunks when calculating 'approxBytesToCopy' and 'approxDocumentsToCopy'

XMLWordPrintableJSON

    • Cluster Scalability
    • Fully Compatible
    • ALL
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Currently, the primary shard is always included as a resharding recipient shard whether or not it is going to own any chunks for the collection after resharding. This is because the listCollections command always targets only the primary shard. Yet, the RecipientCoordinatorService always sets 'approxBytesToCopy' and 'approxDocumentsToCopy' per shard to the total number of bytes and documents divided the number of recipients. This can lead to misleading 'approxBytesToCopy' and 'approxDocumentsToCopy metrics. For example, in the case of moveCollection where the primary shard is not the shard the collection is moving to:

      • The 'approxBytesToCopy' and 'approxDocumentsToCopy' on the primary shard  are equal to the total number of bytes and documents divided 2 instead of 0.
      • The 'approxBytesToCopy' and 'approxDocumentsToCopy' on the shard that the collection is moving to are equal to the total number of bytes and documents divided 2 instead of just the total number of bytes and documents.

              Assignee:
              Cheahuychou Mao
              Reporter:
              Cheahuychou Mao
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: