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.
Server selection occurs once per operation.
The information on this page applies to deployments hosted in the
following environments:
Note
Distributed transactions that contain
read operations must use read preference primary. All
operations in a given transaction must route to the same member.
Server selection occurs once per operation and is governed by the
read preference and localThresholdMS
settings to determine member eligibility for reads. The read preference
is re-evaluated for each operation.
| |
|---|
| The driver selects the primary.
|
| The driver assembles a list of eligible secondary members.
maxStalenessSeconds and tag
sets specified
in the read preference can further restrict the
eligibility of the members. 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. From this list of eligible members that fall within the
latency window, the driver randomly chooses an eligible member.
|
| The driver assembles a list of eligible members (primary and
secondaries). maxStalenessSeconds and tag sets specified
in the read preference can further limit the eligibility
of the members. 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. From this list of eligible members that fall within the
latency window, the driver randomly chooses an eligible member.
|
| If the primary is available, driver selects the primary. If the primary is unavailable, server selection follows
the process for the read preference secondary to select
an eligible secondary member.
|
| Following the server selection process for the read
preference secondary, if a list of eligible secondary
members is non-empty, driver chooses an eligible secondary member. Otherwise, if the list is empty, driver selects the primary.
|
If there is more than one mongos instance in the connection
seed list, the driver determines which mongos is the
"closest" (i.e. the member with the lowest average network
round-trip-time) and calculates the latency window by adding the
average round-trip-time of this "closest" mongos instance
and the localThresholdMS. The driver will load balance randomly
across the mongos instances that fall within the latency
window.
For sharded clusters that have replica set shards, mongos
applies the read preference when reading from the shards. Server
selection is governed by the read preference and replication.localPingThresholdMs
settings. The read preference is re-evaluated for each operation.
Important
Starting in MongoDB 8.0, hedged reads are deprecated. Queries that
specify the read preference nearest no longer use hedged
reads by default. If you explicitly specify a hedged read, MongoDB
performs a hedged read and logs a warning.
mongos supports hedged reads for
non-primary read preference modes.
That is, mongos can send an additional read to another member,
if available, to hedge the read operation if using non-primary
read preferences. The additional read sent to hedge the read operation
uses the maxTimeMS value of maxTimeMSForHedgedReads.
Hedged reads are supported for the following operations:
To use hedged reads:
| |
|---|
| The mongos selects the primary.
|
| The mongos assembles a list of eligible secondary members.
maxStalenessSeconds and tag
sets specified
in the read preference can further restrict the
eligibility of the members. If the list of eligible members is not empty, the
mongos 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 replication.localPingThresholdMs
(or --localThreshold
command line option). The mongos uses this
latency window to pare down the list of eligible members
to those members that fall within this window. From this list of eligible members that fall within the
latency window, the mongos randomly chooses
an eligible member.
|
| The mongos assembles a list of eligible members (primary and
secondaries). maxStalenessSeconds and tag sets specified
in the read preference can further limit the eligibility
of the members. If the list of eligible members is not empty, the
mongos 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 replication.localPingThresholdMs
(or --localThreshold
command line option) . The
mongos uses this latency window to pare
down the list of eligible members to those members that
fall within this window. From this list of eligible members that fall within the
latency window, the mongos randomly chooses
an eligible member.
|
| If the primary is available, mongos selects the primary.
- # . If the primary is unavailable, server
- selection follows the process for the read preference
secondary.
|
| Following the server selection process for the read
preference secondary, if a list of eligible secondary
members is non-empty, mongos chooses an
eligible secondary. If the list of eligible secondary
members is empty or if mongos is using hedged
reads and only one eligible
secondary is available, mongos selects the
primary.
|