Ошибка сегментирования MongoDB в производстве


Мы реализовали концепцию сегментирования mongodb для нашего модуля чата с помощью node + mongodb.

MongoDB Sharding Configuration
===============================
Shard1 = PRIMARY + SECONDARY + ARBITER
Shard2  = PRIMARY + SECONDARY + ARBITER
Config
Mongos

Следующие подробности мы получили сегодня утром. Но мы не знаем, как мы можем решить эту проблему.

Пожалуйста, дайте мне знать, как мы можем решить эту проблему.

" errmsg": "откат 2 ошибка, найдите точку, ожидающую некоторое время, прежде чем повторить попытку"

" errmsg": "ошибка RS102 слишком устаревшая, чтобы ее можно было исправить"

data2:PRIMARY> rs.status()
{
    "set" : "data2",
    "date" : ISODate("2012-07-27T04:30:29Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "50.52.108.16:20001",
            "health" : 1,
            "state" : 9,
            "stateStr" : "ROLLBACK",
            "uptime" : 322,
            "optime" : {
                "t" : 1343361602000,
                "i" : 155
            },
            "optimeDate" : ISODate("2012-07-27T04:00:02Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:29Z"),
            **"errmsg" : "rollback 2 error findcommonpoint waiting a while before trying again"**
        },
        {
            "_id" : 1,
            "name" : "50.52.108.17:20002",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "optime" : {
                "t" : 1343363429000,
                "i" : 7
            },
            "optimeDate" : ISODate("2012-07-27T04:30:29Z"),
            "self" : true
        },
        {
            "_id" : 2,
            "name" : "50.52.108.17:20003",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
            "uptime" : 10880311,
            "optime" : {
                "t" : 0,
                "i" : 0
            },
            "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:28Z")
        }
    ],
    "ok" : 1
}

data1:PRIMARY> rs.status()
{
    "set" : "data1",
    "date" : ISODate("2012-07-27T04:30:17Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "50.52.108.17:10001",
            "health" : 1,
            "state" : 3,
            "stateStr" : "RECOVERING",
            "uptime" : 35,
            "optime" : {
                "t" : 1343320338000,
                "i" : 3
            },
            "optimeDate" : ISODate("2012-07-26T16:32:18Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:16Z"),
            "errmsg" : "error RS102 too stale to catch up"
        },
        {
            "_id" : 1,
            "name" : "50.52.108.16:10002",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "optime" : {
                "t" : 1343363417000,
                "i" : 30
            },
            "optimeDate" : ISODate("2012-07-27T04:30:17Z"),
            "self" : true
        },
        {
            "_id" : 2,
            "name" : "50.52.108.16:10003",
            "health" : 1,
            "state" : 7,
            "stateStr" : "ARBITER",
            "uptime" : 10880162,
            "optime" : {
                "t" : 0,
                "i" : 0
            },
            "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
            "lastHeartbeat" : ISODate("2012-07-27T04:30:16Z")
        }
    ],
    "ok" : 1
}

Кумаран

Author: Kumaran, 2012-07-27

2 answers

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

http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+Replica+Set+Member

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

 6
Author: Aafreen Sheikh, 2012-07-27 06:44:37

Ответ Аафрина верен, и его совет хорош.

Просто обратите внимание на несколько вещей при определении размера вашего oplog, чтобы RS102 не повторился.

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

Оплог

Oplog - это закрытая коллекция, в которой хранятся все операции, изменяющие данные, хранящиеся в MongoDB. Все члены набора реплик имеют оплоги, которые позволяют им поддерживать текущее состояние базы данных. Если вы не измените размер своего oplog с помощью параметра oplogSize, размер oplog по умолчанию будет следующим:

  • Для 64-разрядных систем Linux, Solaris и FreeBSD MongoDB выделит 5% доступного свободного места на диске для оплог.

    Если эта сумма меньше гигабайта, то MongoDB выделит 1 гигабайт пространства.

  • Для 64-разрядных систем OS X MongoDB выделяет 183 мегабайта пространства для oplog.

    Для 32-разрядных систем MongoDB выделяет около 48 мегабайт пространства для oplog.

Как я уже упоминал выше, для каждого слова нет формулы, однако, если вы выполняете много операций записи (вставки/удаления/обновления), вам может потребоваться больший объем (более 5%) в то время как, если это в основном чтение, вам может сойти с рук менее 5 %, это действительно зависит от вашего приложения.

Вот еще одна вводная ссылка на определение размера oplog, которая может помочь немного подробнее объяснить ситуацию, и я также рекомендую прочитать документ Основы репликации.

Оплог на основном сервере является наиболее важным, и рекомендуется, чтобы все оплоги (в наборе реплик) имели одинаковый размер.

 2
Author: Mark Hillick, 2012-07-27 09:52:35