[SERVER-40970] Intelligent "load-aware" loadbalancing mechanism for evenly distributing secondary reads Created: 02/May/19  Updated: 16/Feb/23

Status: Investigating
Project: Core Server
Component/s: Networking
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Harshad Dhavale Assignee: Shameek Ray
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by DRIVERS-864 Round-robin loadbalancing for evenly ... Closed
Related
Sprint: Service Arch 2019-05-20
Participants:
Case:

 Description   

MongoDB drivers use a Server Selection Algorithm to choose which replica set member to use (or, when connected to multiple mongos instances, which mongos instance to use). For a secondary read preference, the server selection process is as follows:

  1. The driver assembles a list of eligible secondary members. maxStalenessSeconds and tag sets can further restrict the eligibility of the members, as documented here.
  2. If the list of eligible members is not empty, the driver determines which eligible member is the “closest” (i.e. the member with the lowest average network round-trip-time) and calculates a latency window by adding the average round-trip-time of this “closest” server and the localThresholdMS. The driver uses this latency window to pare down the list of eligible members to those members that fall within this window.
  3. From this list of eligible members that fall within the latency window, the driver randomly chooses an eligible member.

The above process is documented here. As can be seen here, this process does not use even-load-balancing as a criteria for selection of a secondary. In other words, the secondary selection process does not evenly distribute the incoming queries equally among available secondaries.

 

This is an enhancement request to add an intelligent "load-aware"  loadbalancing mechanism in the Server Selection Algorithm, which will evenly distribute the load among secondaries. Specifically, the mechanism will take into account the current load on each secondary and distribute the query-workload among them accordingly, so that each secondary has approximately the same amount of workload (and not necessarily the same number of read-requests).



 Comments   
Comment by Garaudy Etienne [ 04/Mar/20 ]

kelly.lewis Move it back to open... Will investigate after we've GA'd 4.4.

Generated at Thu Feb 08 04:56:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.