Read Preference

Read preference describes how MongoDB clients route read operations to the members of a replica set.

By default, an application directs its read operations to the primary member in a replica set. Because write operations are issued to the single primary, reading from the primary returns the latest version of a document[1].

For an application that does not require fully up-to-date data, you can improve read throughput or reduce latency by distributing some or all reads to secondary members of the replica set.

IMPORTANT

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. [1]

NOTE

The read preference does not affect the visibility of data; i.e, clients can see the results of writes before they are made durable:

• Regardless of write concern, other clients can see the result of the write operations before the write operation is acknowledged to the issuing client.

• Clients can read data which may be subsequently rolled back.

Use Cases

Indications

The following are common use cases for using non-primary read preference modes:

• Running systems operations that do not affect the front-end application.这并不影响前端应用程序

  NOTE

  Read preferences aren’t relevant有关地 to direct connections to a single mongod instance. However, in order to perform 执行 read operations on a direct connection to a secondary member of a replica set, you must set a read preference, such as secondary.

• 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 read preference or the nearest. This allows the client to read from the lowest-latency members, rather than always reading from the primary.

• Maintaining availability during a failover.故障转移期间保持可用性

  Use primaryPreferred if you want an application to read from the primary under normal circumstances, but to allow stale reads from secondaries in an emergency. This provides a “read-only mode” for your application during a failover.

Counter-Indications

In general, do not use secondary and secondaryPreferred to provide extra capacity for reads 提供额外的读取能力, because:

• 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.

• Because 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.

• Distributing read operations to secondaries can compromise availability 可用性 if any members of the set are 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 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 Read Preference Processes for more information about the internal application of read preferences.

Read Preference Modes

IMPORTANT

All read preference modes except primary may return stale陈旧的 data because secondaries replicate operations from the primary with some delay 延迟. [1] Ensure that your application can tolerate 容忍陈旧 stale data if you choose to use a non-primary mode.

MongoDB drivers support five read preference modes.

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. Themongos instance obeys specified read preferences when connecting to the replica set that provides eachshard in the cluster.

In the mongo shell, the readPref() cursor method provides access to read preferences.

For more information, see read preference background and read preference behavior. See also thedocumentation for your driver.

Tag Sets标签集 不适用于primary read模式

Tag sets allow you to target read operations to specific members of a replica set.

Custom read preferences and write concerns evaluate tags 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 to 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:

• primaryPreferred

• secondary

• secondaryPreferred

• nearest

Tags are not compatible兼容 with mode primary and, in general, only apply when selecting a secondarymember 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.

For more information on how read preference modes interact with tag sets, see the documentation for each read preference mode.