-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
ALL
-
v8.0
-
Cluster Scalability 2024-07-08, Cluster Scalability 2024-07-22, Cluster Scalability 2024-08-19, Cluster Scalability 2024-09-02, Cluster Scalability 2024-10-14, Cluster Scalability 2024-10-28
-
0
To calculate the cardinality and frequency metrics for a shard key that is not unique, the analyzeShardKey command internally runs a cluster aggregate command. To avoid doing a COLLSCAN or an IXSCAN + FETCH stage that may be incurred by shard filtering, the command is run with readConcern "available", and we explicitly document that orphan documents are not excluded from metrics calculation for performance reasons. Using readConcern "available" causes commands to skip both shard version check and shard filtering. Without shard version check, if the cluster aggregate command is routed to the old owning shard(s), it is possible that the no documents would be found as shown in BF-30328.
- depends on
-
SERVER-92087 Allow reads to opt out of shard filtering without using readConcern "available"
- Closed
- is related to
-
SERVER-90727 Fix analyze_shard_key.js to ignore errors related to readConcern: available
- Closed
- related to
-
SERVER-92195 Consider making analyzeShardKey in 8.0.1+ only run cluster aggregate command for calculating cardinality and frequency metrics with readConcern "available" if the collection is sharded
- Closed