复制集读选项¶
复制集读选项决定了在 复制集 中读请求的路由方式。
默认情况下,应用程序将直接在 复制集 的 主节点 上进行读操作。 在主节点上进行读操作确保了读操作返回的数据都是最新的数据。但是,在对数据一致性要求没那么严格的情况下,如果将部分或是所有的读操作分发到复制集的从节点上去处理,能够提升读的性能也能降低应用程序的等待时间。
用例¶
Indications¶
下列是复制集读选项为在非 primary 节点上进行的用例:
执行系统名将不会影响前段的应用。
为地理分布式架构的应用提供了本地读。
如果应用程序服务器分布在多个数据中心,那么我们可以考虑使用 异地分布式架构的复制集 并使用非主节点读取或是 nearest 模式的复制集读选项。这让客户端从最近、延时最低的节点上去读取,而不是在主节点上读取。
在故障切换过程中保持可用性。
我们可以使用 primaryPreferred 让应用程序正常情况下在主节点上进行读取,但是在紧急情况下在从上进行读取。这会让应用程序在故障切换后处于只读状态。
Counter-Indications¶
一般来说,不要用 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.
由于复制是异步的,在写操作执行成功到复制到所有从节点的过程中可能会有延时,在从节点上进行读操作返回的可能不是最新的数据状态。
在从节点上进行分布式的读操作可能会危害到可用性,如果复制集中每个节点都需要相应程序的请求而不作为备用主节点。
如果在分片集群中不使用片键来查询,从节点返回的数据可能会有缺失或是重复,如果chunk迁移还未完成或是中断了的话。
Sharding 是个很好的策略来提升性能,因为它将读写请求分散到多组服务器,并因此提高了读写性能。
更多有关内网内应用的复制集读选项,请参见 复制集读选项的生效流程 。
复制集读选项模式¶
2.2 新版功能.
重要
除了 primary 模式以外的复制集读选项都有可能返回非最新的数据,因为复制过程是异步的, 从节点 上应用操作可能会比主节点有所延后。如果我们不使用 primary 模式,请确保业务允许数据存在可能的不一致。
MongoDB的 驱动 支持5种复制集读选项。
复制集读选项模式 |
详细说明 |
---|---|
primary | 默认模式,所有的读操作都在复制集的 主节点 进行的。 |
primaryPreferred | |
secondary | 所有的读操作都在复制集的 从节点 上执行。 |
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 与标签之间的相互作用。