MongoDB 读取首选项 - 最近与标签集

Question

我的 MongoDB 集群在 3 个 DC 中运行。

DC1 - 3 个节点DC2 - 3 个节点DC3 - 3 个节点

此外，在每个节点中运行我的应用程序。

我正在浏览 MongoDB 文档，并且混淆了黑白最近和标签集。

https://docs.mongodb.com/manual/reference/read-preference/

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:

db.collection.find().readPref('nearest', [ { 'dc': 'east' } ]) Although nearest already favors members with low network latency, including the tag makes the choice more predictable.

根据我的理解。如果我们使用最近的，Driver 将跟踪延迟(还有 maxStalenessSeconds)来决定将流量发送到哪里。如果 DC1 过载或 DC1 延迟很差，Driver 会将流量路由到其他 DC。但是，如果我们使用标签集，那么我们将被迫使用本地 DC，并且如果本地节点关闭，本地应用程序将被视为关闭。为什么我们仍然推荐标签集而不是最近的标签集？

那么，驱动程序如何找到延迟和 maxStalenessSecods？它如何计算延迟？它会持续对集群中的每个节点执行 ping 操作吗？是否可以配置 ping 间隔和重试次数，然后再根据延迟决定节点？

Answer 1

当您使用nearest的readPreference时，您可以指定maxStalenessSecods，例如100。最小值应为 90，否则会抛出错误

延迟是在选择要查询的节点时计算的，因此不会根据时间间隔进行 ping。

当有主节点时:

The client estimates how stale each secondary is by comparing the secondary’s last write to that of the primary

当没有主节点时:

by comparing secondary's last write to the secondary with the most recent write