-
Type: New Feature
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Cluster Scalability
-
Fully Compatible
-
Cluster Scalability Priorities
-
(copied to CRM)
-
200
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.
- related to
-
SERVER-92979 Make resharding account for the number of recipients without chunks when calculating 'approxBytesToCopy' and 'approxDocumentsToCopy'
- Closed
-
SERVER-93075 Investigate if a resharding recipient shard that does not own chunks for the collection after resharding can skip building the indexes for it
- Backlog