Read Preference Use Cases阅读首选项用例

Read Preference Modes读取首选项模式

Indications to Use Non-Primary Read Preference使用非主要读取首选项的指示

The following are common use cases for using non-primary read preference modes:以下是使用非primary读取首选项模式的常见用例：

• 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. 读取首选项与到单个mongod实例的直接连接无关。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.但是，为了在与副本集的次要成员的直接连接上执行读取操作，必须设置读取首选项，例如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 or nearest read preference. 如果您在多个数据中心中有应用程序服务器，您可以考虑使用地理分布的副本集，并使用非主要或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 when the primary is unavailable. 如果您希望应用程序在正常情况下从主应用程序读取数据，但在主应用程序不可用时允许从辅助应用程序读取过时数据，请使用primaryPreferred。This provides a "read-only mode" for your application during a failover.这在故障切换期间为应用程序提供了“只读模式”。

Counter-Indications for Non-Primary Read Preference非主要读取首选项的计数器指示

In general, do not use secondary and secondaryPreferred to provide extra capacity for reads, because:通常，不要使用secondary和secondaryPreferred为读取提供额外容量，因为：

• 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 stale data; reading from different secondaries may result in non-monotonic reads.从辅助设备读取可能会返回过时的数据；从不同的二级读取可能导致非单调读取。

  Changed in version 3.6.在版本3.6中更改。

  Starting in MongoDB 3.6, clients can use Client Sessions and Causal Consistency Guarantees to ensure monotonic reads.从MongoDB 3.6开始，客户端可以使用客户端会话和因果一致性保证来确保单调读取。

• 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.如果集合中的任何成员变得不可用，则将读取操作分发给辅助服务器可能会影响可用性，因为集合中的其余成员需要能够处理所有应用程序请求。

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.有关读取首选项的内部应用的更多信息，请参阅服务器选择算法。

Maximize Consistency最大化一致性

To avoid stale reads, use primary read preference and "majority" readConcern. 要避免过时的读取，请使用primary读取首选项和"majority" readConcern。If the primary is unavailable, e.g. during elections or when a majority of the replica set is not accessible, read operations using primary read preference produce an error or throw an exception.如果主副本不可用，例如，在选举期间或当大多数副本集不可访问时，使用primary读取首选项的读取操作会产生错误或引发异常。

In some circumstances, it may be possible for a replica set to temporarily have two primaries; however, only one primary will be capable of confirming writes with the "majority" write concern.在某些情况下，副本集可能暂时有两个主副本；然而，只有一个主服务器能够确认"majority"写入问题的写入。

• A partial network partition may segregate a primary (P_old) into a partition with a minority of the nodes, while the other side of the partition contains a majority of nodes. 部分网络分区可以将主（P旧）分区为具有少数节点的分区，而分区的另一侧包含大多数节点。The partition with the majority will elect a new primary (P_new), but for a brief period, the old primary (P_old) may still continue to serve reads and writes, as it has not yet detected that it can only see a minority of nodes in the replica set. 多数分区将选择一个新的主分区（P_new），但在很短的一段时间内，旧的Primary（P_old）仍可能继续执行读写操作，因为它尚未检测到只能在副本集中看到少数节点。During this period, if the old primary (P_old) is still visible to clients as a primary, reads from this primary may reflect stale data.在此期间，如果旧的Primary（P_old）仍然作为主对客户端可见，则从该主读取的数据可能反映过时的数据。
• A primary (P _old) may become unresponsive, which will trigger an election and a new primary (P _new) can be elected, serving reads and writes. 初选（P _old）可能变得无反应，这将触发选举，新的初选（P _new）可以被选出，提供读写服务。If the unresponsive primary (P _old) starts responding again, two primaries will be visible for a brief period. 如果无响应的主（P _old）再次开始响应，则两个主将在短时间内可见。The brief period will end when P_old steps down. 当P_old下台时，短暂的时期将结束。However, during the brief period, clients might read from the old primary P _old, which can provide stale data.然而，在短暂的时间内，客户端可能会从旧的PrimaryP _old文件中读取数据，这可能会提供过时的数据。

To increase consistency, you can disable automatic failover; however, disabling automatic failover sacrifices availability.为了提高一致性，您可以禁用自动故障切换；然而，禁用自动故障切换会牺牲可用性。

Maximize Availability最大化可用性

To permit read operations when possible, use primaryPreferred. 若要在可能的情况下允许读取操作，请使用primaryPreferred。When there's a primary you will get consistent reads [1], but if there is no primary you can still query secondaries. 当有主服务器时，您将获得一致的读取[1]，但如果没有primary，您仍然可以查询secondaries。However, when using this read mode, consider the situation described in secondary vs secondaryPreferred.但是，在使用此读取模式时，请考虑secondary vs secondaryPreferred中描述的情况。

Minimize Latency最小化延迟

To always read from a low-latency node, use nearest. 要始终从低延迟节点读取，请使用nearest。The driver or mongos will read from the nearest member and those no more than 15 milliseconds [2] further away than the nearest member.驱动程序或mongos将读取最近的成员以及距离最近成员不超过15毫秒[2]的成员。

nearest does not guarantee consistency. nearest不保证一致性。If the nearest member to your application server is a secondary with some replication lag, queries could return stale data. 如果离应用程序服务器最近的成员是具有一定复制延迟的辅助成员，则查询可能会返回过时数据。nearest only reflects network distance and does not reflect I/O or CPU load.nearest仅反映网络距离，而不反映I/O或CPU负载。

Query From Geographically Distributed Members从地理分布的成员查询

If the members of a replica set are geographically distributed, you can create replica tags based that reflect the location of the instance and then configure your application to query the members nearby.如果副本集的成员在地理上分布，则可以创建反映实例位置的副本标记，然后配置应用程序以查询附近的成员。

For example, if members in "east" and "west" data centers are tagged {'dc': 'east'} and {'dc': 'west'}, your application servers in the east data center can read from nearby members with the following read preference:例如，如果“east”和“west”数据中心中的成员标记为{'dc': 'east'}和{'dc': 'west'}，则您在east数据中心的应用程序服务器可以使用以下读取首选项从附近的成员读取：

db.collection.find().readPref('nearest', [ { 'dc': 'east' } ])

Although nearest already favors members with low network latency, including the tag makes the choice more predictable.尽管nearest已经倾向于网络延迟较低的成员，但包括标签使选择更具可预测性。

secondary vs secondaryPreferred

For specific dedicated queries (e.g. ETL, reporting), you may shift the read load from the primary by using the secondary read preference mode. 对于特定的专用查询（例如ETL、报告），可以使用secondary读取首选项模式将读取负载从主查询转移。For this use case, the secondary mode is preferable to the secondaryPreferred mode because secondaryPreferred risks the following situation: if all secondaries are unavailable and your replica set has enough arbiters [3] to prevent the primary from stepping down, then the primary will receive all traffic from the clients. 对于这种使用情况，secondary模式比secondaryPreferred模式更可取，因为secondaryPreferred模式存在以下风险：如果所有次要模式都不可用，并且您的副本集有足够的仲裁器[3]来防止主要模式降级，则主要模式将接收来自客户端的所有流量。If the primary is unable to handle this load, the queries will compete with the writes. 如果主服务器无法处理此负载，则查询将与写入竞争。For this reason, use read preference secondary to distribute these specific dedicated queries instead of secondaryPreferred.因此，使用读取首选项secondary来分发这些特定的专用查询，而不是secondaryPreferred。