-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
When targeting configServer nodes, we use the minClusterTime as a best effort to filter out stale nodes with respect to the desired configTime. Considering the clusterTime for the node as cached by the RSM can be stale up to 10 seconds and the clusterTimes of each replica are obtained non-atomically and in no specific order, we can end up filtering out the primary. Conceptually, it is impossible for a primary to be more stale than a secondary, shouldn't the recency filter always include primary nodes? (Assuming we somehow fix SERVER-81910, as otherwise we might always target the primary) The streamable replica set monitor guarantees that the primary/secondary knowledge is updated almost immediately (at most as late as the latency to the nodes).
- related to
-
SERVER-81910 Consider making "maxAwaitTimeMS" for streamable hello command configurable
- Backlog