我在诊断Java应用程序对MongoDB的请求没有路由到Nearest副本的问题时遇到了麻烦，希望有人能为您提供帮助。让我开始解释我的配置。
配置:
我正在生产中运行一个Sharded ReplicaSet的MongoDB实例。目前，它只是一个分片(还没有足够大，无法拆分)。该单个分片由3节点副本集支持。副本集的2个节点位于我们的主数据中心中。第三个节点位于我们的辅助数据中心中，被禁止成为主节点。
我们在两个数据中心中同时运行生产应用程序，但是辅助数据中心中的实例以“只读”模式运行，并且永远不会将数据写入MongoDB。它仅为客户请求读取现有数据提供服务。此配置的目的是确保如果我们的主数据中心出现故障，我们仍然可以为客户端读取流量提供服务。
我们不想在辅助数据中心中浪费所有这些硬件，因此即使在欢乐时光，我们也会主动将一部分只读流量负载平衡到在辅助数据中心中运行的应用程序实例。此应用程序实例使用readPreference = NEAREST配置，并指向在本地主机(版本2.6.7)上运行的mongos实例。 mongos实例显然配置为指向我们的3节点副本集。
从蒙哥斯出发:
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时间？或者以某种方式查看传入请求的日志记录，该记录指示已选择的copySet中的节点，为什么？关于如何诊断问题根源的任何建议？
最佳答案
在配置读取首选项时，当ReadPreference = NEAREST时，系统不会寻找最小的网络延迟，因为如果网络连接正确，它可能会将主节点确定为最接近的网络延迟。但是，最接近的读取模式与标记集结合使用时，将选择具有最低网络延迟的匹配成员。甚至最接近的也可能是主要的或次要的。在官方文档中，mongos的行为在配置首选项时以及在网络延迟方面没有得到明确解释。
http://docs.mongodb.org/manual/core/read-preference/#replica-set-read-preference-tag-sets
希望这可以帮助