-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
The "maxAwaitTimeMS" option for a hello command determines the frequency of streamable hello responses from target mongos or mongod. Currently, the "maxAwaitTimeMS" used by the ReplicaSetMonitor is hardcoded to 10 seconds. That is, the ReplicaSetMonitor gets a hello response from a mongod every 10 seconds and every time there is a topology change. The ReplicaSetMonitor uses the hello responses to monitor not only the "serverType" (i.e. primary or secondary) of each mongod but also its "opTime" (i.e. lastDurableOpTime). For configsvr replica set, the "opTime" is used for "minClusterTime" (i.e. the "configOpTime" in the VectorClock) filtering which currently takes precedence over the "roundTripTime" window filtering. It turns out that the 10 seconds can make "opTime"s to be significantly more stale than "configOpTime", causing most of mongods to be filtered out during server selection, including ones that have low "roundTripTime" which should have been given priority in server selection when the readPreference is "nearest".
- is related to
-
SERVER-97232 minClusterTime filtering can filter out primary
- Backlog
-
SERVER-90841 ShardRegistry periodic refresh forces others to block on refresh as well
- Closed
-
SERVER-81580 Make kDefaultConfigCommandTimeout configurable and raise it in slow tests
- Closed