Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Проблема с очисткой базы данных в Windows 2012, UniFi Network
 
Доброе утро! После развертывания масштабного контроллера Unifi мы заметили, что наша база данных mongoDB постоянно растёт, и в итоге проблема возникает из-за нехватки места на жёстком диске. При исследовании вопроса я наткнулся на скрипт prune.js, который отлично работает в Linux, но совсем не справляется в нашей Windows-среде. Поскольку я считаю себя новичком в отладке .js-файлов на Windows, был бы рад, если кто-то подсказал правильное направление, чтобы не пришлось расширять наш HDD каждую неделю! И да, до того как кто-то спросит — я хочу, чтобы это работало именно в Windows из-за ограничений со стороны руководства. Заранее спасибо! Ниже приведена подробная информация:

Версия — 4.6.3 (этими выходными планирую обновиться до 4.6.6)  
ОС — Windows Server 2012  
MongoDB установлена  
Скрипт prune.js помещён в папку /bin, где находится mongo.exe  
Версия Java — 8 Update 40

P.S. Сейчас немного продвинулся. Изучил особенности запуска MongoDB. Создал папку \data\db на диске C: и успешно запустил MongoD. Затем, перейдя в папку с mongo, запустил mongo, но prune.js всё равно не запускается. Обновлённые скриншоты ниже. Также обновил версии:

Версия — 4.6.6  
Версия Java — 8 Update 60
 
Моя папка с данными занимает больше 6 ГБ, а файл unf всего 50 МБ... Не думаю, что там может быть что-то ещё, кроме настроек... Вот что сказано в FAQ: https://help.ubnt.com/hc/en-us/articles/205231940-UniFi-What-is-included-in-the-backup-file-
 
Спасибо за ответ, @szlori! Это хороший вариант, который я, возможно, начну изучать. Мне придётся создать дополнительный контроллер, чтобы проверить эту теорию, потому что мой контроллер недавно перенесли на виртуальную машину. Я создал контрольные точки, однако к тому времени контроллер уже был полностью настроен. Завтра займусь дополнительными исследованиями и тестами, но интересно, сохраняет ли резервная копия только настройки устройств и сайтов? Если да, то это может быть именно то, что мне нужно!
 
Почему бы не виртуализировать сервер и не создавать контрольные точки (термин из Hyper-V, не уверен насчёт других платформ) перед каждым шагом? Так можно сделать встроенное резервное копирование с контроллера, удалить программу, стереть все данные, затем переустановить и восстановить. Отключите автоматические обновления прошивки заранее, и вы не внесёте никаких изменений в устройства, только в контроллер. Если что-то пойдёт не так — просто откатитесь к контрольной точке виртуальной машины.
 
@Uberseehandel

@Deleted Account Есть новости по этому поводу? Меня очень расстраивает, что эта проблема всё еще не решена. Сейчас я вынужден отключать свой беспроводной контроллер, чтобы база данных просто не росла. Это явно не лучшее решение. Как я уже говорил, если есть другой способ просто удалить этот контроллер вместе с базой, скачать новую копию и импортировать все мои сайты и настройки, то это было бы намного проще и удобнее.
 
Если мы не сможем заставить эту базу данных работать правильно, есть ли способ просто удалить эти файлы, не повредив контроллер вместе со всеми подключёнными коммутаторами и точками доступа? Чтобы представить масштаб, у нас развернуто около 70 коммутаторов UniFi и примерно 120 точек доступа. Больше всего боюсь переустановить контроллер, потерять все данные об устройствах и настройках, и потом придётся сбрасывать каждое устройство к заводским настройкам, чтобы оно могло подключиться к новому контроллеру...
 
Резервная копия, которую я использовал, была сделана до того, как я начал свой первый запуск скрипта prune.js в самом начале. К счастью, мой контроллер Unifi до сих пор работает на основе этой копии.
 
Звучит как ваша ошибка. Честно говоря, звучит не очень. Какие ещё резервные копии есть? @Deleted Account, это выглядит плохо — есть у кого опыт с этой проблемой в MongoDB? R+C
 
Хорошо, я приложил два ввода в cmd. Первый — это когда я восстанавливал папку по умолчанию MongoDB \data\db с помощью файлов ace из контроллера Unifi. После выполнения заметил, что в конце процесса появлялась похожая ошибка BSODObj. Честно говоря, я не был уверен, сработало это или нет, поэтому перешёл ко второй команде. Потом снова запустил скрипт prune.js и получил ту же ошибку.
 
@Galaxia

Сейчас у меня немного другие дела. На всех моих серверах стоит только ещё не выпущенная версия UniFi. И так будет до тех пор, пока не появятся прошивки для новых AP-AC с поддержкой RTS и TPC, поэтому проверять то, что я тебе говорю, сейчас не совсем реально — в этом вопросе я полностью под UniFi. Предлагаю сделать копию твоей резервной версии и после установки 64-битной версии MongoDB попробовать зайти в скопированные файлы ace. Если получится, запусти восстановление, сделай резервную копию, если восстановление прошло успешно, а потом снова запусти восстановление. Если всё сработает, снова сделай резервную копию и запусти скрипт очистки. Надеюсь, это поможет! R+C
 
Спасибо за ваш ответ! Все данные контроллера у меня сохранены и находятся на совершенно другом сетевом ресурсе. Я проверил это, удалив всю папку db из папки Unifi и скопировав туда резервную копию — контроллер успешно запустился вместе со всеми данными.
 
Прежде чем что-то делать, обязательно сделай резервную копию всех своих данных. R+C
 
Не знаю, есть ли у кого-то информация по этому поводу, но у меня есть обновление. Сейчас у меня возникла проблема: размер BSONObj слишком большой, и из-за этого скрипт не запускается. Я пытался искать решения этой ошибки, и мне советовали попробовать починить базу данных. Но прежде чем делать что-то, хочу уточнить у кого-то ещё.

@, заметил, что ты вполне опытен в вопросах взаимодействия Unifi и MongoDB, поэтому прошу тебя помочь. Я читал несколько твоих сообщений по этой теме, но так и не смог понять, как связаны они с моей проблемой. Если у тебя найдётся хоть небольшое руководство или совет, буду очень признателен!
Страницы: 1
Читают тему (гостей: 1)