Mongodb ReadPreference=最近的Mongos路由

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

配置：

我正在生产环境中运行一个MongoDB实例，它是一个分片复制集。它目前只是一个碎片（它还没有大到需要分割）。此单个碎片由一个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时间？或者以某种方式查看传入请求的日志记录，这表明选择了replicaSet中的节点及其原因？关于如何诊断我的问题的根本原因有什么建议吗？

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

---

希望这能有所帮助

如果我使用flag-vvv（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)

---

如何确切地防止第二个数据中心中的服务器成为主服务器？您可以发布

sh.status（）

和

rs.status（）

的输出吗？您可以防止优先级为0的节点成为主节点有几种方法可以防止节点成为主节点，只是希望确保它没有被隐藏。；）有趣的问题。。。