Признание устаревшего члена клана монго

Если узел mongo слишком долго отключен, а обложки oplog перед тем, как он возвращается, он может застрять в устаревшем состоянии и потребовать ручного вмешательства. Как я могу узнать это состояние из документа статуса набора реплик? Будет ли он вставляться в состояние 3, которое также используется узлами в режиме обслуживания и, предположительно, узлами, которые могут догнать? Если да, то как я могу сказать разницу?

Из http://docs.mongodb.org/manual/reference/replica-status/ </а>:

Number State
0      Starting up, phase 1 (parsing configuration)
1      Primary
2      Secondary
3      Recovering (initial syncing, post-rollback, stale members)
4      Fatal error
5      Starting up, phase 2 (forking threads)
6      Unknown state (the set has never connected to the member)
7      Arbiter
8      Down
9      Rollback
10     Removed

3
nl ja de

1 ответы

Это будет в состоянии 3, Восстановление. Чтобы распознать устаревшее состояние, вам нужно искать поле errmsg . Когда он устареет, у вторичного объекта будет errmsg:

"errmsg" : "error RS102 too stale to catch up"

Что касается полной производительности, он будет выглядеть примерно так:

 rs.status()
{
        "set" : "testReplSet",
        "date" : ISODate("2013-01-29T01:39:38Z"),
        "myState" : 1,
        "members" : [
                {
                        "_id" : 0,
                        "name" : "hostname:31000",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 507,
                        "optime" : Timestamp(1359423456000, 893),
                        "optimeDate" : ISODate("2013-01-29T01:37:36Z"),
                        "self" : true
                },
                {
                        "_id" : 1,
                        "name" : "hostname:31001",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 483,
                        "optime" : Timestamp(1359423456000, 893),
                        "optimeDate" : ISODate("2013-01-29T01:37:36Z"),
                        "lastHeartbeat" : ISODate("2013-01-29T01:39:37Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 2,
                        "name" : "hostname:31002",
                        "health" : 1,
                        "state" : 3,
                        "stateStr" : "RECOVERING",
                        "uptime" : 4,
                        "optime" : Timestamp(1359423087000, 1),
                        "optimeDate" : ISODate("2013-01-29T01:31:27Z"),
                        "lastHeartbeat" : ISODate("2013-01-29T01:39:38Z"),
                        "pingMs" : 0,
                        "errmsg" : "error RS102 too stale to catch up"
                }
        ],
        "ok" : 1
}

И, наконец, фрагмент кода для распечатки ошибки, если она существует, из оболочки:

rs.status().members.forEach(function printError(rsmember){if (rsmember.errmsg){print(rsmember.errmsg)}})
4
добавлено
Звучит неплохо. Я подал ошибку docs с 10gen, и они были очень отзывчивы. Ключевым моментом является то, что если узел обнаруживает, что он слишком устарел, он автоматически выполнит начальную синхронизацию jira .mongodb.org/просмотр/DOCS-1064 .
добавлено автор Fasaxc, источник
DBA - русскоговорящее сообщество
DBA - русскоговорящее сообщество
1 345 участник(ов)

Общаемся и обсуждаем темы, посвященные DBA, PostgreSQL, Redis, MongoDB, MySQL, neo4j, riak и т.д. См. также: @devops_ru, @kubernetes_ru, @docker_ru, @nodejs_ru Рекомендуем сразу отключить уведомления, чтобы пребывание здесь было полезным и комфортным.

MongoDB Russian
MongoDB Russian
1 086 участник(ов)

> db.stats() https://combot.org/chat/-1001035023078