复制集读选项¶
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.
注解
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:
- Regardless of write concern, other clients using "local" (i.e. the default) readConcern can see the result of a write operation before the write operation is acknowledged to the issuing client.
- Clients using "local" (i.e. the default) readConcern can read data which may be subsequently rolled back.
用例¶
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.
为地理分布式架构的应用提供了本地读。
如果应用程序服务器分布在多个数据中心，那么我们可以考虑使用 异地分布式架构的复制集 并使用非主节点读取或是 nearest 模式的复制集读选项。这让客户端从最近、延时最低的节点上去读取，而不是在主节点上读取。
在故障切换过程中保持可用性。
我们可以使用 primaryPreferred 让应用程序正常情况下在主节点上进行读取，但是在紧急情况下在从上进行读取。这会让应用程序在故障切换后处于只读状态。
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.
- 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 是个很好的策略来提升性能，因为它将读写请求分散到多组服务器，并因此提高了读写性能。
更多有关内网内应用的复制集读选项，请参见 Server Selection Algorithm 。
复制集读选项模式¶
重要
除了 primary 模式以外的复制集读选项都有可能返回非最新的数据，因为复制过程是异步的， 从节点 上应用操作可能会比主节点有所延后。如果我们不使用 primary 模式，请确保业务允许数据存在可能的不一致。
MongoDB drivers support five read preference modes.
复制集读选项模式 |
详细说明 |
|---|---|
| primary | 默认模式，所有的读操作都在复制集的 主节点 进行的。 |
| primaryPreferred | |
| secondary | All operations read from the secondary members of the replica set. |
| secondaryPreferred | |
| nearest | 读操作会在 复制集 中网络延时最小的节点上进行，与节点类型无关。 |
指定复制集读选项模式的语法参见 specific to the driver and to the idioms of the host language 。
复制集读选项对通过 mongos 来对 分片集群 进行连接也有效 。当通过 mongos 对 分片 的 复制集 进行连接时，我们也可以使用复制集选项来指定连接对象。
在 mongo shell中，通过游标 readPref() 来指定复制集读选项。
参见 read preference background 、 read preference behavior 和 documentation for your driver 。
标签设置¶
标签设置可以让我们将
复制集读选项与安全写级别获取标签的方式是不同的。当需要选择从哪个节点进行读操作的时候，复制集读选项会参考的是标签的值。安全写级别在选择节点的时候只考虑标签的值是否为唯一，与标签的具体数值无关。
你可以通过标签来指定如下的复制集读选项：
标签一般而言只适用于在 从节点 上进行 查询 请求的复制集读选项，而不适用于 primary 模式。当 nearest 模式与标签结合使用的时候，就会匹配最低网络延时的节点。这个节点可能是从节点也可能是主节点。
所有的交互都是基于复制集读选项模式与标签的，且使用了同样的 用户选择逻辑 来将选择分发读请求的节点。
参见 配置复制集标签设置 获得更多有关标签配置的信息。
参见 documentation for each read preference mode 与标签之间的相互作用。
| [1] | (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 { w: "majority" } write concern. The node that can complete { w: "majority" } writes is the current primary, and the other node is a former primary that has not yet recognized its demotion, typically due to a network partition. When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary, and new writes to the former primary will eventually roll back. |