Вторичные MongoDB не догоняют - PullRequest
3 голосов
/ 12 мая 2011

У меня есть набор реплик, который я пытаюсь обновить основной до одного с большим объемом памяти и обновленным дисковым пространством.Таким образом, я проверил несколько дисков вместе на новом первичном сервере, rsync сделал данные с вторичного устройства и добавил их в набор реплик.После проверки rs.status () я заметил, что все вторичные серверы находятся примерно в 12 часах позади первичного.Поэтому, когда я пытаюсь принудительно установить новый сервер на основной сервер, он не будет работать, потому что он не обновлен.

Это кажется большой проблемой, потому что в случае сбоя основного сервера мы находимся наминимум 12 часов и около 48 часов позади.

Все оплоги перекрываются, и размер оплогов довольно велик.Единственное, что я могу понять, это то, что я выполняю много операций записи / чтения на первичном сервере, что может удерживать сервер в заблокированном состоянии, не позволяя должным образом догнать его.

Есть ли способ принудительно вызватьвторичный, чтобы догнать первичный?

В настоящее время существует 5 серверов, причем последние 2 должны заменить 2 других узла.Узел с _id, равным 6, должен заменить основной.Узел, который находится дальше всего от основного времени работы, отстает чуть более чем на 48 часов.

{
"set" : "gryffindor",
"date" : ISODate("2011-05-12T19:34:57Z"),
"myState" : 2,
"members" : [
    {
        "_id" : 1,
        "name" : "10******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 20231,
        "optime" : {
            "t" : 1305057514000,
            "i" : 31
        },
        "optimeDate" : ISODate("2011-05-10T19:58:34Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 2,
        "name" : "10******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 20231,
        "optime" : {
            "t" : 1305056009000,
            "i" : 400
        },
        "optimeDate" : ISODate("2011-05-10T19:33:29Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 3,
        "name" : "10******:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 20229,
        "optime" : {
            "t" : 1305228858000,
            "i" : 422
        },
        "optimeDate" : ISODate("2011-05-12T19:34:18Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 5,
        "name" : "10*******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 20231,
        "optime" : {
            "t" : 1305058009000,
            "i" : 226
        },
        "optimeDate" : ISODate("2011-05-10T20:06:49Z"),
        "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
    },
    {
        "_id" : 6,
        "name" : "10*******:27018",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "optime" : {
            "t" : 1305050495000,
            "i" : 384
        },
        "optimeDate" : ISODate("2011-05-10T18:01:35Z"),
        "self" : true
    }
],
"ok" : 1
}

Ответы [ 2 ]

1 голос
/ 12 мая 2011

Я не уверен, почему синхронизация не удалась в вашем случае, но один из способов перебора синхронизации - удалить файлы данных из реплики и перезапустить mongod.Это инициирует повторную синхронизацию.См. http://www.mongodb.org/display/DOCS/Halted+Replication. Это может занять некоторое время, в зависимости от размера вашей базы данных.

0 голосов
/ 13 мая 2011

После просмотра всего я обнаружил одну ошибку, которая привела меня обратно к mapreduce, который был запущен на первичном сервере, с этой проблемой: https://jira.mongodb.org/browse/SERVER-2861.Поэтому, когда была предпринята попытка репликации, она не синхронизировалась из-за неисправной / поврежденной операции в журнале операций.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...