ReadPreference=NEAREST 的 Mongos 路由

Question

我无法诊断我的 Java 应用程序对 MongoDB 的请求没有被路由到最近的副本的问题，我希望有人能提供帮助。让我先解释一下我的配置。

配置：

我正在运行生产中的一个 MongoDB 实例，它是一个 Sharded ReplicaSet。它目前只有一个分片（它还没有大到需要拆分）。这个单个分片由一个 3 节点副本集支持。副本集的 2 个节点位于我们的主数据中心。第三个节点在我们的二级数据中心，禁止成为主节点。

我们运行我们的生产应用程序同时在两个数据中心，但是我们辅助数据中心的实例在 "read-only" 模式下运行并且从不将数据写入 MongoDB。它仅服务于客户端请求读取现有数据。这个配置的 objective 是为了确保如果我们的主数据中心出现故障，我们仍然可以为客户端读取流量提供服务。

我们不想在我们的辅助数据中心浪费所有这些硬件，所以即使在快乐的时候，我们也会主动将一部分只读流量负载平衡到我们的应用程序实例运行ning在辅助数据中心。此应用程序实例配置了 readPreference=NEAREST，并指向本地主机（版本 2.6.7）上的 mongos 实例运行ning。 mongos 实例显然配置为指向我们的 3 节点副本集。

来自 mongos:

mongos> sh.status()
--- Sharding Status --- 
sharding version: {
"_id" : 1,
"version" : 4,
"minCompatibleVersion" : 4,
"currentVersion" : 5,
"clusterId" : ObjectId("52a8932af72e9bf3caad17b5")
}
shards:
{  "_id" : "shard1",  "host" : "shard1/failover1.com:27028,primary1.com:27028,primary2.com:27028" }
databases:
{  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
{  "_id" : "test",  "partitioned" : false,  "primary" : "shard1" }
{  "_id" : "MyApplicationData",  "partitioned" : false,  "primary" : "shard1" }

来自副本集的故障转移节点：

shard1:SECONDARY> rs.status()
{
"set" : "shard1",
"date" : ISODate("2015-09-03T13:26:18Z"),
"myState" : 2,
"syncingTo" : "primary1.com:27028",
"members" : [
{
    "_id" : 3,
    "name" : "primary1.com:27028",
    "health" : 1,
    "state" : 1,
    "stateStr" : "PRIMARY",
    "uptime" : 674841,
    "optime" : Timestamp(1441286776, 2),
    "optimeDate" : ISODate("2015-09-03T13:26:16Z"),
    "lastHeartbeat" : ISODate("2015-09-03T13:26:16Z"),
    "lastHeartbeatRecv" : ISODate("2015-09-03T13:26:18Z"),
    "pingMs" : 49,
    "electionTime" : Timestamp(1433952764, 1),
    "electionDate" : ISODate("2015-06-10T16:12:44Z")
},
{
    "_id" : 4,
    "name" : "primary2.com:27028",
    "health" : 1,
    "state" : 2,
    "stateStr" : "SECONDARY",
    "uptime" : 674846,
    "optime" : Timestamp(1441286777, 4),
    "optimeDate" : ISODate("2015-09-03T13:26:17Z"),
    "lastHeartbeat" : ISODate("2015-09-03T13:26:18Z"),
    "lastHeartbeatRecv" : ISODate("2015-09-03T13:26:18Z"),
    "pingMs" : 53,
    "syncingTo" : "primary1.com:27028"
},
{
    "_id" : 5,
    "name" : "failover1.com:27028",
    "health" : 1,
    "state" : 2,
    "stateStr" : "SECONDARY",
    "uptime" : 8629159,
    "optime" : Timestamp(1441286778, 1),
    "optimeDate" : ISODate("2015-09-03T13:26:18Z"),
    "self" : true
}
],
"ok" : 1
}


shard1:SECONDARY> rs.conf()
{
    "_id" : "shard1",
    "version" : 15,
    "members" : [
    {
        "_id" : 3,
        "host" : "primary1.com:27028",
        "tags" : {
            "dc" : "primary"
        }
    },
    {
        "_id" : 4,
        "host" : "primary2.com:27028",
        "tags" : {
            "dc" : "primary"
        }
    },
    {
        "_id" : 5,
        "host" : "failover1.com:27028",
        "priority" : 0,
        "tags" : {
            "dc" : "failover"
        }
    }
    ],
    "settings" : {
        "getLastErrorModes" : {"ACKNOWLEDGED" : {}}
    }
}

问题：

问题是在我们的辅助数据中心命中此 mongos 的请求似乎被路由到我们主数据中心的副本运行ning，而不是最近的节点，即运行ning在辅助数据中心。这会导致大量网络延迟并导致读取性能不佳。

我的理解是 mongos 正在决定将请求路由到副本集中的哪个节点，并且它应该遵守我的 java 驱动程序请求中的 ReadPreference。我可以在 mongos shell 中运行查看副本集的状态，包括对节点的 ping 时间吗？或者以某种方式查看传入请求的日志记录，这些请求指示被选择的 replicaSet 中的节点以及为什么？关于如何诊断我的问题的根本原因有什么建议吗？

Answer 1

在配置读取首选项时，当 ReadPreference = NEAREST 时，系统不会寻找最小网络延迟，因为如果网络连接正确，它可能会将主节点确定为最近的。但是，最近读取模式与标签集结合使用时，会选择网络延迟最低的匹配成员。甚至最近的可能是主要或次要的任何一个。配置首选项时 mongos 的行为以及网络延迟方面在官方文档中的解释并不那么清楚。

http://docs.mongodb.org/manual/core/read-preference/#replica-set-read-preference-tag-sets

希望这对您有所帮助

Answer 2

如果我使用标志 -vvvv（4x 详细）启动 mongos，那么我会在日志文件中看到请求路由信息，包括有关使用的读取首选项和请求路由到的主机的信息。例如：

2015-09-10T17:17:28.020+0000 [conn3] dbclient_rs say 
using secondary or tagged node selection in shard1, 
read pref is { pref: "nearest", tags: [ {} ] } 
    (primary : primary1.com:27028, 
    lastTagged : failover1.com:27028)

Answer 3

尽管措辞不同，但在使用最近时，绝对最快的成员不一定是所选成员。相反，从延迟低于计算的 延迟 window.

的成员池中随机选择一个成员

延迟window是取最快成员的ping加上replication.localPingThresholdMs计算的，默认为15ms。您可以阅读有关算法的更多信息 here.

所以我所做的是将 nearest 与标签相结合，以便我可以手动指定我知道在地理位置上最近的成员。

ReadPreference=NEAREST 的 Mongos 路由

Mongos routing with ReadPreference=NEAREST

mongodb

spring-data-mongodb

mongodb-java