-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
ALL
-
0
Reducing stale version retries when analyze_shard_key.js is running in concurrent_sharded_*_balancer appears to make this test timeout less frequently, but why does the command take several minutes in the presence of such retries?
SERVER-95078 implements an option to reduce the number of retries for analyzeShardKey, but the question of where the time goes when there are retries still stands. When we find the cause of the delay, and if it can be removed or reduced, we may consider removing the option of reducing the number of retries.
- related to
-
SERVER-95078 Make number of retries for StaleVersion configurable for analyzeShardKey queries
- Closed