КАК: Починить MongoDB на Linux

КАК: Починить MongoDB на Linux, UniFi Network

PetriR

Guest

08.01.2018 11:43:00

Ладно, теперь до меня дошло. После автоматического обновления Debian контроллер не запускался. Из логов я выяснил, что проблема была в том, что MongoDB нужно было восстановить. У меня получилось только с нескольких попыток. Вот что помогло:

service unifi stop
pkill -KILL mongo
if [ -f /var/lib/unifi/db/WiredTiger.lock ]; then rm /var/lib/unifi/db/WiredTiger.lock; fi
su -c "mongod --dbpath /var/lib/unifi/db --repair" unifi
service unifi start

Сначала нужно остановить контроллер. Это также закроет MongoDB. У меня оставались какие-то процессы, которые держали файлы, поэтому пришлось использовать pkill. Можно заменить на killall, если у вас есть такая команда (но не используйте killall5!).
Если есть файл блокировки — удалите его. Можно проверить и сделать это вручную.
Самая большая проблема была в том, что запускать команду восстановления от root’а нельзя — тогда часть файлов будет принадлежать root, а восстанавливать нужно от пользователя unifi. Процесс восстановления требует много свободного места на диске, проверьте, чтобы загрузка не была выше 60% по df -h.
После этого перезапустите контроллер и зайдите в систему.
Все пути и команды приведены для Debian-подобных систем, возможно, вам придется подкорректировать их под свою ОС.
Если это не поможет, лучше полностью удалить контроллер и начать заново из последней резервной копии. Резервные копии у вас есть, да?

PetriR

Guest

25.08.2018 07:32:00

Да, это и следовало ожидать. Вы отключили журналирование для ремонтного запуска. Как только MongoDB запускается с обычными параметрами (включая журналирование), он восстановит журнал. Это хорошее наблюдение, от которого могут выиграть и другие — в том числе на других платформах.

rallystar

Guest

25.08.2018 06:46:00

Думаю, с ведением журнала всё ещё всё в порядке. Я проверил файловую систему после того, как убедился, что всё снова работает. Она заполнила каталог журнала чем-то, что похоже на файл журнала. Я тоже не эксперт по mongo, но у меня сработало переименование каталога журнала и запуск ремонта. Только что заметил, что вышли новые версии FW и UniFi, так что жму на кнопку обновления. Держу пальцы крестиком.

PetriR

Guest

25.08.2018 06:40:00

Помню, где-то читала, что журналирование включили совсем недавно на CKs. Это хорошая новость для надёжности софта, но плохая — для внутреннего накопителя, у которого ограничено количество циклов записи. Журналирование меняет то, как работает опция восстановления. Я, конечно, не эксперт по MongoDB, но, судя по всему, если убрать, переименовать или скрыть директорию журнала, система возвращается к старому поведению без журналирования. Вот почему у тебя и получился такой опыт.

rallystar

Guest

25.08.2018 05:51:00

Немного дополню — я разбирался с CK, где всё вышеперечисленное и процедуры UBNT не помогали. Mongo сообщал, что есть файлы журнала. Я пытался запускать --repair без --smallfiles, но это не решало проблему. В итоге я переместил папку /usr/lib/unifi/data/db/journal в journal_old, затем запустил ремонт с --smallfiles, и всё очистилось. Странно! В основном оставляю это здесь, чтобы не забыть, если снова случится...

PetriR Guest	#6 07.08.2018 12:39:00 Спасибо за отчёт. Cloud Key — это довольно простой дистрибутив Debian. Я стараюсь их избегать, поэтому у меня не было такой под рукой для тестирования.

truedatasupport

Guest

06.08.2018 10:59:00

Для тех, кто нашёл эту ветку и нуждается в инструкции по ремонту Cloud Key. Можно использовать большую часть вышеуказанных указаний, но изменить расположение базы данных на: /usr/lib/unifi/data/db. Это сработало лучше, чем инструкции от UBNT. Ссылка вот здесь: https://help.ubnt.com/hc/en-us/articles/360006634094-UniFi-SDN-Identifying-Database-Issues-on-the-Cloud-Key

PetriR

Guest

15.06.2018 08:09:00

Файл блокировки существует не просто так. Он предотвращает одновременную работу двух экземпляров MongoDB с одной и той же директорией базы данных. Если процесс MongoDB внезапно «упал», файл блокировки может остаться «осиротевшим». Если файл блокировки есть, а процесса нет — это верный признак, что что-то пошло не так.

Коммутаторы, USG, камеры и прочее отлично работают без контроллера. VPN-соединения устанавливаются между USG, а не контроллерами. Контроллеры нужны только для внесения изменений в конфигурацию — в обычной эксплуатации это нормально.

Твои проблемы могут быть связаны с аппаратными неполадками. Cloud Keys сильно греются, возможно, это проблема с питанием или ошибки флэш-накопителя.

Я везде, где могу, избегаю использования Cloud Keys. Сейчас мой любимый вариант — запускать контроллер в облачном сервисе. Чтобы упростить задачу, я написал скрипт, который разворачивает контроллер со всеми необходимыми функциями (включая автоматический ремонт MongoDB) на бесплатной виртуальной машине Google Cloud. Если хочешь попробовать, я написал статью, как сделать это за 15 минут. Забудь про проблемы с Cloud Keys!

david-b

Guest

14.06.2018 20:22:00

Понял, единственное, что я вижу — это mongod.lock, но предполагаю, что он там, потому что Mongo всё ещё работает. Меня особо не беспокоят наши точки доступа во время перезагрузки контроллера или восстановления/простоя, беспокоит всё остальное, что с этим контроллером связано. (2 USG с VPN site-to-site и USW, в котором работают подсети для рабочих станций, IP-камер и VoIP). Похоже, придется отправиться ночью или рано утром в наш филиал, где стоит контроллер, чтобы разобраться, что к чему. Честно говоря, не понимаю, почему у этого устройства вдруг начались проблемы с интерфейсом после года нормальной работы без всяких сбоев. На самом деле, единственное нововведение — это запуск точек доступа после того, как всё остальное уже было настроено и работало. Вот такое дело, lol.

PetriR

Guest

#10

14.06.2018 19:56:00

Ubiquiti не публиковала никакой точной информации про признаки здоровья базы данных, да и я не эксперт по MongoDB. Я нашёл два файловых флага и два lock-файла, которые мой скрипт проверяет (условия if [ -f ... ]). Обычно, если есть проблема, все они присутствуют. Идея была в том, чтобы починить базу данных до запуска контроллера. Не думаю, что базу можно чинить на ходу. Контроллер не обязателен для работы WLAN сети и обслуживания пользователей. Только функция хотспота и некоторые сервисы (например, RADIUS) требуют работающий контроллер. Можно выключить контроллер, а точки доступа спокойно продолжат работать.

david-b

Guest

#11

14.06.2018 18:58:00

Отличный пост, спасибо, что поделились! У меня возникла проблема, которая, как мне кажется, связана с MongoDB. Не могу найти ни одного поста с похожими симптомами: стартовая страница CloudKey работает, а страница контроллера (кнопка «управление») постоянно таймаутится, и страница управления CloudKey (кнопка «настройка») показывает запрос на вход, но при отправке ничего не происходит. Все найденные мной посты с похожими проблемами как раз указывают на «грязную» базу MongoDB.

У меня была точно такая же проблема в прошлом месяце, и перезагрузка CloudKey через SSH вроде решала её. Правда, после первой перезагрузки CloudKey решил перезагрузиться сам ещё раз. При этом на втором перезапуске мы ненадолго потеряли VPN-соединение site-to-site через USG, наверное, произошло переобновление конфигурации.

Так что я бы хотел найти способ исправить эту проблему без необходимости каждый раз перезагружать CloudKey, и, если возможно, без полного сброса и восстановления. Есть ли способ проверить, требует ли MongoDB ремонта? И вызовет ли запуск вашего скрипта какие-либо сбои для подключённых пользователей?

Заранее спасибо за помощь!

PetriR

Guest

#12

17.05.2018 12:17:00

Запуск --repair не должен нанести никакого вреда. Он переписывает внутренние структуры MongoDB. Если с ними всё в порядке, результат будет идентичен исходному. Если есть какие-то записи UniFi, которые правильно сохранены и индексированы, но «неправильны» с точки зрения UniFi, ремонт этого не исправит.

wrobertnelson

Guest

#13

17.05.2018 11:19:00

У меня проблемы с ошибкой дешифровки на некоторых точках доступа, которая, как я думаю, вызвала повреждение MongoDB во время миграции. Вы знаете, поможет ли запуск --repair очистить такие «призрачные» записи? Я ничего не понимаю в Linux, поэтому пытаюсь разобраться, как проверить наличие ошибочных записей в базе данных и удалить их. Контроллер работает на сервере Digital Ocean.

PetriR Guest	#14 02.03.2018 13:59:00 Если хотите автоматизировать этот процесс так, чтобы он запускался при каждом старте системы для ремонта после некорректного завершения работы, вам понадобятся два файла (для систем на базе systemd, например Debian). Поместите следующий скрипт в /usr/local/sbin/unifidb-repair.sh: #! /bin/sh if ! pgrep mongod; then if [ -f /var/lib/unifi/db/mongod.lock ] \ \|\| [ -f /var/lib/unifi/db/WiredTiger.lock ] \ \|\| [ -f /var/run/unifi/db.needsRepair ] \ \|\| [ -f /var/run/unifi/launcher.looping ]; then if [ -f /var/lib/unifi/db/mongod.lock ]; then rm -f /var/lib/unifi/db/mongod.lock; fi if [ -f /var/lib/unifi/db/WiredTiger.lock ]; then rm -f /var/lib/unifi/db/WiredTiger.lock; fi if [ -f /var/run/unifi/db.needsRepair ]; then rm -f /var/run/unifi/db.needsRepair; fi if [ -f /var/run/unifi/launcher.looping ]; then rm -f /var/run/unifi/launcher.looping; fi su -c "/usr/bin/mongod --repair --dbpath /var/lib/unifi/db --logappend --logpath /usr/lib/unifi/logs/mongod.log" unifi fi else echo "MongoDB запущен. Выход..." exit 1 fi Сделайте скрипт исполняемым командой: chmod a+x /usr/local/sbin/unifidb-repair.sh Создайте unit-файл сервиса для systemd в /etc/systemd/system/unifidb-repair.service: [Unit] Description=Ремонт базы данных UniFi MongoDB при загрузке Before=unifi.service mongodb.service After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/usr/local/sbin/unifidb-repair.sh [Install] WantedBy=multi-user.target Включите сервис, чтобы он запускался при следующей загрузке системы: systemctl enable unifidb-repair.service

Читают тему (гостей: 1)