Состояние STARTUP2 означает, что узел не может голосовать. Член RS входит в это состояние, когда процесс MongoD завершает загрузку своей конфигурации. В этом состоянии участник создал потоки для обработки внутренних операций репликации, но ему еще предстоит изменить состояние на Восстановление и далее с этого на Вторичное (см. [Состояние и их подробности в документации]) .
Если ваш узел находился в этом состоянии более короткого периода времени, то вы столкнулись с некоторым странным поведением. Это почти невозможно проанализировать без логов, чтобы определить, почему они застряли. Запуск rs.status () и db.printSlaveReplicationInfo () даст вам некоторые подробности о локальном изображении на узле.
Обычный подход к решению этой проблемы - закрыть узел, стереть его файлы данных (эти файлы в dbpath) и перезапустить его. Это перезапустит начальный процесс синхронизации, и он должен перейти к ВТОРИЧНОМУ. Если он снова застрянет в STARTUP2, вам нужно будет просмотреть журналы, чтобы собрать больше информации о причинах - существует ряд причин, но может произойти нестабильная сеть или конфликт локальных ресурсов.
Следует отметить, что во время начальной синхронизации узел останется в STARTUP2, поэтому в зависимости от объема синхронизируемых данных это может занять значительное количество времени (возможно, дней).
show databases
терпит неудачу сnot master and slaveOk=false