Как стать автором
Обновить

Руководство по выживанию с MongoDB

Время на прочтение 12 мин
Количество просмотров 34K
Всего голосов 58: ↑58 и ↓0 +58
Комментарии 9

Комментарии 9

Не раскрыты действительно животрепещущие вопросы:


  • как бэкапить(в т.ч. инкрементально) и восстанавливать данные?
  • что делать, если кластер развалился?
  • монга тупит. ваши действия?
  • как добавлять/удалять/заменять ноды без даунтайма?
  • как делать миграции?
* что делать если восстановление индекса занимает неделю?
на мой дилетанский взгляд ответ тут очевиден — отказаться от монги и пересмотреть архитектуру
НЛО прилетело и опубликовало эту надпись здесь
1. Бекапить снапшотами файловой системы. lvm|zfs вам в помощь.
2. Логи читать. Следить за версиями mongo|mongos.
3. Глянуть в мониторинг, в текущие запросы. В слоу лог.
4. Работа с нодами отлично описана в офф документации.
5. А что мигрировать? Схемы нет. Данные — валидируйте и обновляйте на уровне своего приложения.
— Инкрементального бекапа там нет. можно извратится и бекапить оплог. Но потом восстановление с такого бекапа будет долгим. Обычный бекап можно делать удаленно. Тогда нагрузка на живом сервере будет только на диск и сеть. А сжатие бекапа на удаленном сервере. Плюс есть снэпшоты целого диска. Для больших данных самое оно (если позволяет сервер)
— Искать причины разваливания кластера! Если правильно кластер построен — то у вас минимум есть две реплики и один арбитр. По хорошему то всего нужно по три) Три реплики, три конфиг-сервера и две mongoos. В моей практике падали только сервера. Но за счет резервирования по серверам — все само восстанавливалось. Проблема может быть когда сервер упал и оооочень долго не подымался. И если есть интенсивные изменения и маленький размер оплога — то тогда могут быть проблемы. Вплоть до того что реплика не поднимется из-за нехватки оплога. Решений такой ситуации неколько: увеличить оплог на примари / стопнуть (зафризить) сервер и скопировать данные сразу / поднять реплику без «автопостроения» индексов.
— Тупит в каком плане? Смотрите mongostat. Смотрите на запросы. Решения в статье были. Это изменение политики записи / использование слейвов на чтение
— Добавление удаление нод — реализовано на ура. Только правило такое — что оплог должен быть большим! И что кол-во нод в реплике не должно быть четным. Управление репликами на чтение и т.п. решается конфигами и настройками приложения
— Миграции в no-sql? Тут или управление на стороне приложения. Или прохождение по всем документами и изменение содержимого. Если пробежать и поменять тип поля — то лучше через консоль и js кодом миграции. Работает хорошо. На млрд — коллекциях долго но прошуршит все. Тут только помнить о времени жизни курсора. Или выбирать чанками (при условии что данные не удаляются)

Стать можно еще многим дополнить. Например это «предварительное шардирование». Это когда вы создаете чанки заранее и распихиваете их на нужные шарды в нужной вам пропорции и гранулярности. Потом на этой коллекции отключение автошардирование — и проблемы с автобалансировкой пропадает. И в такие коллекции можно писать очень активно без боязни что что-то будет удаляться
  • Мы делали специальную инвизную реплику для бэкапов. Отсоединяешь от кластера и бэкапишь как хочешь.
  • Чтоб было меньше шансов на развал кластера, сделать 2 арбитра.
  • Ну тут нужно смотреть на состояние машины в целом и логи
  • Если вы про, «мгновенно добавить secondory ноду, чтоб уже была синхронизированна», то пока даже не знаю в какую сторону тут смотреть
  • Посмотреть на готовые решение, своих у них пока что-то не видно

Монга когда то казалась классной штукой.
Дальше чистое имхо как вы понимаете.
Потом я попробовал каучбейз, в нем многих из этих проблем нет, просто шардить и бэкапить и вообще выглядит как продукт для людей. При этом функционал не теряется.

Если класть туда все подряд и использвать еще и lookup(join) для связки между коллекциями, то да, база свалится с грохотом. Если же все делать правильно и хранить только горячие данные (+ 1 к perfomance) и использовать избыточность для пересбора документов (что — бы убить «join») (+ 1 к perfomance). То никаких гарантий о записи не потребуется (+ 1 к perfomance). Архитектуру для хранения в Монге необходимо делать грамотно, а не как тут. Все костыли которые в данный момент вы использовали, просто не нужны, если архитектура приложения адекватная. Вывод: Монга подходит для хранения горячих данных средних объемов + пересбор на выходе для уменьшения общего количества запросов, для большого количества данных лучше использовать другую базу, например ClickHouse. Если же пытаться засунуть все га… но в монгу, то безусловно можно и нужно просто дать в зубы архитектору за это)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий