Борьба с бинарными логами MySQL в Ubuntu

Привет, коллеги! Сегодня хочу поделиться реальной историей, которая научила меня одному важному уроку администрирования серверов. Если у вас VPS с Ubuntu, на котором работает несколько сайтов через ISPmanager, эта статья может спасти вас от многих часов беспокойства.

Симптомы проблемы

Всё началось с того, что сайты начали периодически падать с ошибкой 502 Bad Gateway. При этом сервер оставался доступен по SSH, сервисы nginx и apache2 показывали статус active (running), но часть сайтов (особенно работающих на Joomla) отказывалась работать.

Проверка ресурсов показала тревожную картину:

• Дисковое пространство было заполнено на 85%
• Оперативная память иногда исчерпывалась, вызывая срабатывание OOM-killer
• В логах MySQL мы обнаружили сотни файлов бинарных логов

Диагностика: метод тыка или системный подход?

Первое, что мы сделали — проверили логи падающих сайтов. Например, для сайта vizator.ru мы увидели ошибки:

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted

Это указывало на проблему с памятью PHP. Но после отключения "тяжелого" модуля Joomla «Кто на сайте» проблема с сайтом временно исчезла.

Однако дисковое пространство продолжало стремительно заполняться. И здесь мы нашли главного виновника:

sudo du -xh / | sort -rh | head -20

Эта команда показала, что /var/lib/mysql/ занимал более 33 ГБ из 78 ГБ диска! Детальный анализ выявил сотни файлов вида binlog.000001, binlog.000002 и т.д. — это были бинарные логи MySQL.

Проверка настроек подтвердила проблему:

sudo mysql -e "SHOW VARIABLES LIKE 'log_bin';"
# Результат: log_bin = ON

sudo mysql -e "SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';"
# Результат: 604800 (7 дней)

В официальных настройках MySQL в ISPmanager было включено ведение бинарных логов с хранением на 7 дней. При активной работе Joomla и WordPress сайтов это создавало колоссальный объем данных.

Решение: как остановить "пожирателя" диска

Шаг 1: Немедленное освобождение места

Первым делом мы очистили старые логи:

sudo mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 DAY;"

Это сразу освободило около 30 ГБ дискового пространства.

Шаг 2: Постоянное ограничение хранения

Мы изменили срок хранения бинарных логов с 7 дней до 1 дня:

sudo mysql -e "SET GLOBAL binlog_expire_logs_seconds = 86400;"

Шаг 3: Отключение бинарных логов

Поскольку мы не используем репликацию и точечное восстановление (PITR), а бэкапы ISPmanager работают через mysqldump, мы решили полностью отключить бинарные логи.

Важно: ISPmanager игнорирует изменения в основном конфигурационном файле и перезаписывает их при каждом обновлении. Поэтому правильное решение — создать override-файл:

# Останавливаем MySQL
sudo systemctl stop mysql

# Удаляем существующие логи
sudo rm -f /var/lib/mysql/binlog.*

# Создаем файл с приоритетными настройками
echo '[mysqld]
skip-log-bin
' | sudo tee /etc/mysql/conf.d/99-zzz-disable-binlog.cnf

# Запускаем MySQL
sudo systemctl start mysql

Проверка подтвердила успех:

sudo mysql -e "SHOW VARIABLES LIKE 'log_bin';"
# Теперь: log_bin = OFF

Шаг 4: Создание надежной защиты

Чтобы ISPmanager не вернул настройки после обновления, мы закрепили наш override-файл:

sudo chattr +i /etc/mysql/conf.d/99-zzz-disable-binlog.cnf

Эта команда делает файл неизменяемым даже для пользователя root.

Важные нюансы решения

1. Безопасность отключения binlog: Если вы не используете репликацию или точечное восстановление баз данных (PITR), отключение бинарных логов абсолютно безопасно. Резервные копии ISPmanager и ручные дампы через mysqldump продолжат работать.
2. Почему ISPmanager включает binlog по умолчанию? Панель управления ISPmanager активирует бинарные логи как "безопасный вариант" на случай, если администратор захочет использовать продвинутые функции восстановления данных. Но на практике большинство пользователей в этом не нуждаются.
3. Дополнительная очистка: Не забудьте проверить другие "пожиратели" дискового пространства:

   sudo journalctl --vacuum-time=3d  # очистка системных логов
   sudo du -sh /var/log/nginx/ /var/log/apache2/  # проверка логов веб-серверов

Возможно, это еще не конец истории...

Несмотря на все меры, я остаюсь настороже. ISPmanager — мощная панель управления, но иногда она может переопределить наши настройки после обновления или автоматической корректировки конфигурации.

Я настроил мониторинг свободного места на диске и буду получать уведомления, если заполнение превысит 80%. Также в cron добавлена еженедельная команда для принудительной очистки старых логов.

Если проблема вернется — я готов углубиться в шаблоны конфигурации ISPmanager и найти способ постоянного отключения бинарных логов на уровне панели управления.

Полезные ресурсы

• Официальная инструкция ISPmanager по ограничению бинарных логов — подробное руководство с дополнительными методами оптимизации.
• MySQL 8.0 Reference Manual: The Binary Log — полная документация от разработчиков MySQL.
• Systemd Journal Administration — руководство по управлению системными логами.

Итоги

Эта история научила меня нескольким важным вещам:

1. Всегда проверяйте не только логи приложений, но и использование дискового пространства
2. Настройки панелей управления могут переопределять ваши правки в конфигах
3. Для решения проблем с дисковым пространством иногда требуется многоуровневый подход
4. Профилактика лучше, чем лечение — настройте мониторинг заранее

Надеюсь, эта статья поможет вам избежать подобных проблем или быстро решить их, если они возникнут. Делитесь вашими историями в комментариях — вместе мы можем найти решение любой серверной головоломки!