Чому Монго застряг у STARTUP2?

У мене є Mongoнабір реплік з кількома вторинниками. Ящик, у якому розміщений вторинний екземпляр, розбився і втратив базу даних.

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

Що саме означає STARTUP2? Це копіювання бази даних з первинної? Як я можу це перевірити (якщо припустити, що Mongo працює в Linux)?

Відповідь еоінбразилу частково невірна. Новий Вузол може тривалий час знаходитися в STARTUP2. Посилання, що розміщується, говорить:

Кожен член набору реплік переходить у стан STARTUP2, як тільки mongod закінчує завантаження конфігурації цього члена, і в цей час він стає активним членом набору реплік. Потім учасник вирішує, чи слід здійснювати початкову синхронізацію чи ні. Якщо учасник починає початкову синхронізацію, член залишається в STARTUP2, поки всі дані не будуть скопійовані і не будуть створені всі індекси. Після цього член переходить до ВІДНОВЛЕННЯ.

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

show databases

або ви також можете спостерігати за каталогом даних, щоб побачити, чи все ще зростає. (у Linux з командами ls, df, du, iotop тощо.)

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

Якщо ваш вузол перебуває в такому стані більше короткого періоду, тоді ви стикаєтеся з якоюсь дивною поведінкою. Це неможливо проаналізувати без журналів, щоб визначити, чому він застряг. Запуск rs.status () та db.printSlaveReplicationInfo () надасть вам деякі відомості про локальне зображення на вузлі.

Нормальним підходом до вирішення цього питання є вимкнення вузла, стерти його файли даних (ті файли на dbpath) та перезапустити його. Це відновить початковий процес синхронізації, і він повинен перейти до SECONDARY. Якщо він знову застряг у STARTUP2, вам потрібно буде переглянути журнали, щоб зібрати більше інформації щодо причин - існує цілий спектр причин, але одна з цих ситуацій може бути невмілою мережею або певними локальними ресурсами.

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

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

Під час повторної синхронізації учасника переконайтеся, що RS не перебуває під великим навантаженням.

Стан STARTUP2 може виникнути через недостатньо місця на диску. Отже, оскільки немає де синхронізувати, він може залишатися лише в стані @ STARTUP2.