Mongo 2.6.4 не будет stepDown(), потому что не может найти вторичный в течение 10 секунд, но rs.status() показывает синхронизированные opttimeDates

Я пытаюсь отказаться от своего основного монго и взять на себя мои вторичные - монго не уйдет и говорит, что мои вторичные устройства не синхронизированы более чем на 10 секунд. Тем не менее, мой набор реплик говорит, что они синхронизированы - я сбит с толку и, вероятно, что-то глупое, что я упускаю

вот мой вывод:

MongoDB shell version: 2.6.4
sessionV2:PRIMARY> rs.stepDown()
{
    "closest" : NumberLong(0),
    "difference" : NumberLong(1441842526),
    "ok" : 0,
    "errmsg" : "no secondaries within 10 seconds of my optime"
}
sessionV2:PRIMARY> rs.status()   
{
    "set" : "sessionV2",
    "date" : ISODate("2015-09-09T23:48:53Z"),
    "myState" : 1,
    "members" : [
        {
        "_id" : 0,
        "name" : "sessionv2-mongo-replset-moprd1-02:27017",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 2659,
        "optime" : Timestamp(1441842533, 61),
        "optimeDate" : ISODate("2015-09-09T23:48:53Z"),
        "electionTime" : Timestamp(1441839881, 1),
        "electionDate" : ISODate("2015-09-09T23:04:41Z"),
        "self" : true
    },
    {
        "_id" : 1,
        "name" : "sessionv2-mongo-replset-moprd1-01:27017",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 2658,
        "optime" : Timestamp(1441842531, 120),
        "optimeDate" : ISODate("2015-09-09T23:48:51Z"),
        "lastHeartbeat" : ISODate("2015-09-09T23:48:51Z"),
        "lastHeartbeatRecv" : ISODate("2015-09-09T23:48:51Z"),
        "pingMs" : 0,
        "syncingTo" : "sessionv2-mongo-replset-moprd1-03:27017"
    },
    {
        "_id" : 2,
        "name" : "sessionv2-mongo-replset-moprd1-03:27017",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 2658,
        "optime" : Timestamp(1441842531, 120),
        "optimeDate" : ISODate("2015-09-09T23:48:51Z"),
        "lastHeartbeat" : ISODate("2015-09-09T23:48:51Z"),
        "lastHeartbeatRecv" : ISODate("2015-09-09T23:48:52Z"),
        "pingMs" : 0,
        "syncingTo" : "sessionv2-mongo-replset-moprd1-02:27017"
    }
],
"ok" : 1
}
sessionV2:PRIMARY> 

вот что первичные отчеты о статусе:

sessionV2:PRIMARY>  rs.printSlaveReplicationInfo()
    source: sessionv2-mongo-replset-moprd1-01:27017
    syncedTo: Wed Sep 09 2015 19:15:02 GMT-0500 (CDT)
    1 secs (0 hrs) behind the primary 
    source: sessionv2-mongo-replset-moprd1-03:27017
    syncedTo: Wed Sep 09 2015 19:15:02 GMT-0500 (CDT)
    1 secs (0 hrs) behind the primary 
    sessionV2:PRIMARY> 

и вид оплога из вторичного:

sessionV2:SECONDARY> db.getReplicationInfo()
{
"logSizeMB" : 5120,
"usedMB" : 5077.25,
"timeDiff" : 12226,
"timeDiffHours" : 3.4,
"tFirst" : "Wed Sep 09 2015 15:53:29 GMT-0500 (CDT)",
"tLast" : "Wed Sep 09 2015 19:17:15 GMT-0500 (CDT)",
"now" : "Wed Sep 09 2015 19:17:15 GMT-0500 (CDT)"
}

заранее спасибо!

Обновление от 10 сентября 2015 г.: мы остановили каждый вторичный сервер и выполнили первоначальную синхронизацию с основным, а затем снова попытались отключить основной – похоже, что ОСНОВНОЙ не может найти вторичный oplogDate (мы не были уверены, что принудительное принуждение освободит ВТОРИЧНЫЙ для выполнения НАЧАЛЬНЫЙ)

sessionV2:PRIMARY> db.runCommand( { replSetStepDown: 60, force: false } ) 
{
"closest" : NumberLong(0),
"difference" : NumberLong(1441936029),
"ok" : 0,
"errmsg" : "no secondaries within 10 seconds of my optime"
}

person avavavavava    schedule 09.09.2015    source источник


Ответы (1)


проблема решена! - Я играл с обходными путями и документировал настройку реплики - наши первоначальные сценарии задавали первичному приоритет по умолчанию, а вторичным - приоритет 0 (что означает, что они никогда не возьмут на себя ОСНОВНУЮ роль) - так что в основном -> плохая конфигурация и сообщение об ошибке не не давать никакой информации о корневой проблеме (документация довольно ясна, просто пропустил ее, потому что я доверял нашим сценариям инициализации) - если вы столкнулись с этим, и ваши оплоги набора реплик обновлены, дважды проверьте, что приоритеты не установлены на 0

person avavavavava    schedule 18.09.2015