Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Вы большой молодец. Статья отличная, почти ничего лишнего, спасибо.
Про каталог rollback — у нас для каждого data directory есть триггер на количество файлов в нём и его подкаталогах. Советую, полезная вещь.
Ещё из вроде как сугубо технических вещей могу посоветовать не игнорировать совет из документации хранить данные WT на XFS. На ext4 в момент WT checkpoint даже на относительно свежих ядрах всё плохо, latency даже на SSD взлетает в сотни раз.
Подготовка сервера к нагрузке — это целый комплекс мероприятий.
Никакие советы из документации не надо игнорировать.
Кроме WT на XFS, надо еще:
* выключить THP,
* настроить синхронизацию времени всех серверов проекта с одного источника,
* проверить реальную производительность дисковой подсистемы по скорости и параллелизму операций с помощью mongoperf,
* увеличить ограничения сервиса в systemd (пример)
Это что всем полезно будет.
У нас же регламент еще касается проверки сети, настройки мониторинга и бекапов.
Никакие советы из документации не надо игнорировать.
Кроме WT на XFS, надо еще:
* выключить THP,
* настроить синхронизацию времени всех серверов проекта с одного источника,
* проверить реальную производительность дисковой подсистемы по скорости и параллелизму операций с помощью mongoperf,
* увеличить ограничения сервиса в systemd (пример)
Это что всем полезно будет.
У нас же регламент еще касается проверки сети, настройки мониторинга и бекапов.
Мониторить каталог rollback нет необходимости.
Если требуется получить не откатываемые данные, то явно ожидайте w:majority.
Если ожидание ограничено мастером, то бизнес-логика должна быть тертима к некоторому откату данных.
В процессе эксплуатации в rollback всегда что либо попадает.
Мы там ищем данные в случае нарушения структуры БД по вине бизнес-логики.
Если требуется получить не откатываемые данные, то явно ожидайте w:majority.
Если ожидание ограничено мастером, то бизнес-логика должна быть тертима к некоторому откату данных.
В процессе эксплуатации в rollback всегда что либо попадает.
Мы там ищем данные в случае нарушения структуры БД по вине бизнес-логики.
Про rollback не соглашусь, у нас там бывает что-нибудь крайне редко (потому что w:majority стоит по умолчанию). Кроме того, я ещё помню как в 2015 году мы из-за бага в MongoDB доставали из rollback несколько гигабайт данных =)
Rollback — это всегда следствие смены ведущего сервера.
У нас тоже данные туда попадают не часто, т.к. сеть стабильная, а техобслуживание серверов мы стараемся минимизировать.
Но, совершенно точно rollback не зависит от режима ожидания записи.
Вам на постоянной основе требуется мониторить rollback с учетом ожидания w:majority?
А какие проблемы вы таким образом решаете?
У нас тоже данные туда попадают не часто, т.к. сеть стабильная, а техобслуживание серверов мы стараемся минимизировать.
Но, совершенно точно rollback не зависит от режима ожидания записи.
Вам на постоянной основе требуется мониторить rollback с учетом ожидания w:majority?
А какие проблемы вы таким образом решаете?
Спасибо за статью очень полезная. Мы тоже планируем перейти к монго вот и читаем изучаем опыт других компаний
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB на вырост