Question

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

配置：

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

我们在两个数据中心同时运行我们的生产应用程序，但是我们的辅助数据中心的实例在＆＃34;只读＆＃34;模式，永远不会将数据写入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" }

从replicaset的故障转移节点：

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

如果我用标志-vvvv（4x verbose）启动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 2

不管措辞如何，当使用 nearest 时，绝对最快的成员不一定是选择的成员。相反，会从延迟低于计算出的延迟窗口的成员池中随机选择一个成员。

延迟窗口是通过取最快成员的ping并添加replication.localPingThresholdMs来计算的，其默认值为15ms。您可以阅读有关算法 here 的更多信息。

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

使用ReadPreference的Mongos路由= NEAREST

2 个答案: