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. This allows the client to read from the lowest-latency members, rather than always reading from the primary.如果您在多个数据中心中有应用程序服务器，则可以考虑使用地理分布的复制副本集，并使用非primary或nearest读取首选项。这允许客户端从延迟最低的成员读取，而不是总是从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"读取关注。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 _old）划分为具有少数节点的分区，而分区的另一侧包含大多数节点。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），但在很短的一段时间内，旧的主分区仍可能继续提供读写服务，因为它尚未检测到它只能看到副本集中的少数节点。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.在此期间，如果客户端仍然可以看到旧的主服务器（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.但是，在短时间内，客户端可能会从旧的primary P _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]，但如果没有主数据库，您仍然可以查询辅助数据库。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. 不能保证一致性。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:例如，如果“东部”和“西部”数据中心的成员被标记为{'dc': 'east'}和{'dc': 'west'}，则东部数据中心的应用程序服务器可以使用以下读取首选项从附近的成员读取：

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。