-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Cluster Scalability
-
Fully Compatible
-
ALL
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.
- is related to
-
SERVER-92978 Make sure resharding recipients can restore 'approxDocumentsToCopy' and 'approxBytesToCopy' metrics after failover
- Closed
-
SERVER-91109 Optimize resharding when primary shard owns zero chunks for resharded collection
- Closed
-
SERVER-94114 Resharding's approxDocumentsToCopy metric can be incorrect.
- Closed