We have made a lot of changes to the balancer. As a result, clusters with a high number of sharded collections may see slower balancing. In trying to find how many clusters have a high number of sharded collections, we realize that serverStatus doesn't give us this information.
We should track the number of sharded collections in a cluster and place that information in serverStatus. It would help to backport this to all the versions.
something like "numShardedCollections" or "catalogStatus.shardedCollections" may suffice.
This can be a lazy/slow count, aka can we do this in a way that doesn't impact customer workloads?
- causes
-
SERVER-74720 The default 'shardingStatistics' serverStatus section takes locks
-
- Closed
-
- is documented by
-
DOCS-15745 Investigate changes in SERVER-68576: We need to know how many sharded collections exist in a cluster
-
- Closed
-
- related to
-
-
- Closed
-