Больше года назад мы в LEADS.SU задумались над высокодоступностью нашей БД и начали искать различные варианты. Круг решений сужало то, что мы используем TokuDB, который уже не поддерживается. Вариантов было несколько, но точно было понятно что запуск кластера повлечет за собой полное клонирование файлов /var/lib/mysql, к тому моменту размер этой директории уже перевалил за пару сотен гигабайт и мы задумались над ревизией данных, что привело к долгоиграющему процессу по уменьшению размера БД.

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

В прошлый раз мы рассматривали внедрение Sentry со стороны эксплуатации: устанавливали на сервер self-hosted, делали его высокодоступным при помощи сети доставки td-agent, настраивали мониторинг.

Теперь рассмотрим процесс внедрения Sentry со стороны команды разработки.

Привет! Я Виталий, DevOps в LEADS.SU, в этой статье хочу рассказать как мы внедряли Sentry self-hosted и приводили к продакшен состоянию, которое должно отвечать требованиям высокодоступности - нельзя терять события ошибок. При этом не хотелось заморачиваться с кластеризацией для разных инструментов (вроде redis, postgresql, clickhouse, kafka и прочее). И тут мы вспомнили про распределенную сеть доставки логов из нескольких узлов td-agent и решили попробовать.