Маршрут Mongos с ReadPreference = NEAREST

У меня возникла проблема с диагностикой проблемы, когда мои запросы Java-приложения к MongoDB не попадают в ближайшую реплику, и я надеюсь, что кто-то может помочь. Позвольте мне начать с объяснения моей конфигурации.

Конфигурация:

Я запускаю экземпляр MongoDB, который является Sharded ReplicaSet. В настоящее время это всего лишь один осколок (он еще недостаточно развит, но требует раскола). Этот одинарный осколок поддерживается набором реплик 3 node. В нашем основном центре обработки данных находятся 2 узла набора реплик. Третий node живет в нашем вторичном центре данных и ему запрещено становиться мастером node.

Мы запускаем наше производственное приложение одновременно в обоих центрах обработки данных, однако экземпляр в нашем вторичном центре обработки данных работает в режиме "только для чтения" и никогда не записывает данные в MongoDB. Он обслуживает только клиентские запросы для чтения существующих данных. Цель этой конфигурации - обеспечить, чтобы, если наш основной центр обработки данных снизился, мы все равно можем обслуживать трафик чтения клиента.

Мы не хотим тратить все это оборудование в нашем вторичном центре обработки данных, поэтому даже в счастливые времена мы активно загружаем баланс части нашего трафика только для чтения в экземпляр нашего приложения, работающего во вторичном центре обработки данных. Этот экземпляр приложения настроен с помощью readPreference = NEAREST и указывается на экземпляр mongos, запущенный на localhost (версия 2.6.7). Экземпляр mongos, очевидно, настроен так, чтобы указывать на наш набор реплик < node.

Из монго:

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" }

В режиме восстановления node репликатора:

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" : {}}
    }
}

Проблема:

Проблема заключается в том, что запросы, которые попадают в этот монго в нашем вторичном центре обработки данных, как представляется, направляются на реплику, запущенную в нашем основном центре обработки данных, а не на ближайший node, который работает во вторичном центре данных. Это приводит к значительным задержкам в сети и приводит к плохой производительности чтения.

Мое понимание заключается в том, что mongos решает, какой node в наборе реплик должен направить запрос, и он должен соблюдать ReadPreference из моего запроса драйвера java. Есть ли команда, которую я могу запустить в оболочке mongos, чтобы увидеть статус набора реплик, включая время ping для узлов? Или каким-то способом увидеть входные запросы, указывающие на node в выбранном реплике, и почему? Любой совет вообще о том, как диагностировать первопричину моей проблемы?