-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
A newly-elected shard primary can block serving user operations while waiting to install sharding metadata. This process can take a long time for users with lots of config metadata. To address this issue, in SERVER-55412 began mirroring the ShardVersion field to secondaries, so that they would be more likely to incrementally keep their sharding information up-to-date, and have less to refresh after an election.
We should compare the time-to-first-majority write after an election on a replica set vs. a sharded cluster, to ensure this feature is working. We should experiment with different values of the ratio of reads we mirror, to examine the sensitivity. We should be particular to examine a case where there are lots of collections, which implies more metadata to refresh.
- related to
-
SERVER-55412 Mirrored reads should propagate the shard version field
- Closed