Read preference describes how MongoDB clients route read operations to the members of a replica set.
Exercise care when specifying read preferences: Modes other than
primary may return stale data because with
asynchronous replication, data in
the secondary may not reflect the most recent write operations.
The read preference does not affect the visibility of data; i.e, clients can see the results of writes before they are acknowledged or have propagated to a majority of replica set members:
The following are common use cases for using non-
read preference modes:
Running systems operations that do not affect the front-end application.
Providing local reads for geographically distributed applications.
If you have application servers in multiple data centers, you may consider having a geographically distributed replica set and using a non primary or
nearestread preference. This allows the client to read from the lowest-latency members, rather than always reading from the primary.
Maintaining availability during a failover.
primaryPreferredif you want an application to read from the primary under normal circumstances, but to allow stale reads from secondaries when the primary is unavailable. This provides a “read-only mode” for your application during a failover.
- All members of a replica have roughly equivalent write traffic; as a result, secondaries will service reads at roughly the same rate as the primary.
- Replication is asynchronous and there is some amount of delay between a successful write operation and its replication to secondaries. Reading from a secondary can return out-of-date data; reading from different secondaries may result in non-monotonic reads.
- Distributing read operations to secondaries can compromise availability if any members of the set become unavailable because the remaining members of the set will need to be able to handle all application requests.
- For queries of sharded collections, for clusters with the balancer active, secondaries may return stale results with missing or duplicated data because of incomplete or terminated chunk migrations.
Sharding increases read and write capacity by distributing read and write operations across a group of machines, and is often a better strategy for adding capacity.
See Server Selection Algorithm for more information about the internal application of read preferences.
Read Preference Modes¶
All read preference modes except
primary may return
stale data because secondaries replicate
operations from the primary with some delay.
 Ensure that your application can tolerate
stale data if you choose to use a non-
MongoDB drivers support five read preference modes.
|Read Preference Mode||Description|
||Default mode. All operations read from the current replica set primary.|
||In most situations, operations read from the primary but if it is unavailable, operations read from secondary members.|
||All operations read from the secondary members of the replica set.|
||In most situations, operations read from secondary members but if no secondary members are available, operations read from the primary.|
||Operations read from member of the replica set with the least network latency, irrespective of the member’s type.|
The syntax for specifying the read preference mode is specific to the driver and to the idioms of the host language.
Read preference modes are also available to clients connecting to a
sharded cluster through a
mongos instance obeys specified read preferences when
connecting to the replica set that provides each shard
in the cluster.
Tag sets allow you to target read operations to specific members of a replica set.
Custom read preferences and write concerns evaluate tag sets in different ways. Read preferences consider the value of a tag when selecting a member to read from. Write concerns ignore the value of a tag when selecting a member, except to consider whether or not the value is unique.
You can specify tag sets with the following read preference modes:
Tags are not compatible with mode
primary and, in general, only
apply when selecting
a secondary member of a set for a read operation. However, the
nearest read mode, when combined with a tag set, selects
the matching member with the lowest network latency. This member may be a
primary or secondary.
All interfaces use the same member selection logic to choose the member to which to direct read operations, basing the choice on read preference mode and tag sets.
For information on configuring tag sets, see the Configure Replica Set Tag Sets tutorial.
|||(1, 2) In some circumstances, two nodes in a replica set
may transiently believe that they are the primary, but at most, one
of them will be able to complete writes with |