Почему Монго застрял в STARTUP2?

13

У меня есть Mongoнабор реплик с несколькими второстепенными. Коробка, на которой размещен вторичный экземпляр, потерпела крах и потеряла базу данных.

Я Mongoснова запустил вторичный экземпляр, и теперь он застрял в STARTUP2 более чем на 12 часов. Имеет ли это смысл ? Документы говорят, что Mongoдолжны быть в STARTUP2 в течение короткого периода времени, прежде чем войти в состояние RECOVERING

Что конкретно означает STARTUP2? Это копирование базы данных с первичной? Как я могу это проверить (при условии, что Mongo работает в Linux)?

mongodb recovery Майкл
источник

Ответы:

12

Ответ eoinbrazil частично неверен. Новый узел может находиться в STARTUP2 в течение длительного времени. Ссылка размещена говорит:

Каждый член набора реплик переходит в состояние STARTUP2, как только mongod заканчивает загрузку конфигурации этого элемента, и в этот момент он становится активным членом набора реплик. Затем участник решает, следует ли выполнить первоначальную синхронизацию. Если участник начинает первоначальную синхронизацию, он остается в STARTUP2 до тех пор, пока все данные не будут скопированы и все индексы не будут построены. После этого участник переходит к ВОССТАНОВЛЕНИЮ.

Я управляю коллекцией в 700 ГБ, и когда я добавляю новый узел, состояние STARTUP2 остается более 24 часов. Но вы все еще можете увидеть, если что-то происходит, наблюдая, растет ли база данных. Вы можете увидеть размер базы данных на новом узле с

show databases

или вы также можете наблюдать каталог данных, чтобы увидеть, продолжает ли он расти. (в linux с командами ls, df, du, iotop и т. д ....)

Кенякорн Кецомбут
источник
1
show databasesтерпит неудачу сnot master and slaveOk=false
JDPeckham
Просматривая логи, вы можете видеть прогресс. Например, он будет отображать что-то вроде: [rsSync] Index Build: 2538000/22982417 11%
Даниэль Бенедикт
4

Состояние STARTUP2 означает, что узел не может голосовать. Член RS входит в это состояние, когда процесс MongoD завершает загрузку своей конфигурации. В этом состоянии участник создал потоки для обработки внутренних операций репликации, но ему еще предстоит изменить состояние на Восстановление и далее с этого на Вторичное (см. [Состояние и их подробности в документации]) .

Если ваш узел находился в этом состоянии более короткого периода времени, то вы столкнулись с некоторым странным поведением. Это почти невозможно проанализировать без логов, чтобы определить, почему они застряли. Запуск rs.status () и db.printSlaveReplicationInfo () даст вам некоторые подробности о локальном изображении на узле.

Обычный подход к решению этой проблемы - закрыть узел, стереть его файлы данных (эти файлы в dbpath) и перезапустить его. Это перезапустит начальный процесс синхронизации, и он должен перейти к ВТОРИЧНОМУ. Если он снова застрянет в STARTUP2, вам нужно будет просмотреть журналы, чтобы собрать больше информации о причинах - существует ряд причин, но может произойти нестабильная сеть или конфликт локальных ресурсов.

Следует отметить, что во время начальной синхронизации узел останется в STARTUP2, поэтому в зависимости от объема синхронизируемых данных это может занять значительное количество времени (возможно, дней).

eoinbrazil
источник
Благодарю. Мы удалили данные и перезапустили Mongo. Это все еще в STARTUP2. Похоже, Монго работает. Это потребляет процессор и, как я вижу, в db.statsбазе данных растет. В журнале написано, что некоторые объекты cloned. Я все еще ищу возможные причины этой проблемы.
Майкл
1
Если это все еще проблема, вы можете просто сделать копию с другого узла (см. Эту процедуру - docs.mongodb.org/manual/tutorial/resync-replica-set-member/… ). Если вы можете прикрепить журналы, подсвечивающие детали и информацию о том, какую версию вы используете, это может указывать на причину, но в равной степени это необычное поведение. Вы пробовали пинг между узлами, чтобы увидеть, какова задержка сети?
eoinbrazil
Mongo 2.4.6 pingмежду хостами это ок.
Майкл
Каково время пинга, поскольку это может быть периодические проблемы с сетью? В этом случае гораздо проще, если бы вы могли добавить некоторые выходные данные журнала, поскольку это нестандартное поведение и журналы являются основным источником правды при попытке определить, что именно происходит.
eoinbrazil
Боюсь, я не могу показать здесь логи. Однако я заметил, что он пытается подключиться к другому вторичному члену, который не работает. Может ли это быть причиной проблемы?
Michael
1

Одной из возможных причин является то, что ваш вторичный стал "устаревшим", как указано здесь .

При повторной синхронизации участника убедитесь, что RS не находится под большой нагрузкой.

user2829759
источник
0

Состояние STARTUP2 может быть связано с нехваткой места на диске. Ну, поскольку синхронизировать некуда, он может оставаться только в состоянии @ STARTUP2.

Эзоп Ли
источник