Почему Монго застрял в 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.

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