mongodb - 使用 ReadPreference=NEAREST 的 Mongos 路由

Question

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

配置:

我正在生产中运行一个 MongoDB 实例，它是一个 Sharded ReplicaSet。它目前只有一个分片(它还没有变得足够大，需要拆分)。此单个分片由 3 节点副本集支持。副本集的 2 个节点位于我们的主数据中心。第三个节点位于我们的辅助数据中心，被禁止成为主节点。

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

我们不想在我们的辅助数据中心浪费所有这些硬件，因此即使在快乐的时候，我们也会主动将部分只读流量负载平衡到在辅助数据中心中运行的应用程序实例。此应用程序实例配置为 readPreference=NEAREST 并指向在 localhost(版本 2.6.7)上运行的 mongos 实例。 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 的请求似乎被路由到在我们的主数据中心中运行的副本，而不是在辅助数据中心中运行的最近节点。这会导致大量的网络延迟并导致读取性能不佳。

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

Answer 1

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

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

希望对你有帮助