Server Admin Авторский блог системного администратора
В один прекрасный момент мониторинг zabbix прислал оповещение о том, что на одном из серверов заканчивается место на диске. Просмотр занятого места быстро выявил виновника события - бинарные логи mysql-bin.00000, mysql-bin.00001 и так далее в папке /var/lib/mysql. Стал разбираться, что это за файлы и зачем они нужны.
Разбираться громко сказано. Я и раньше знал, что это бинарные логи базы. Для одной из баз на сервере была настроена репликация, для этого указан бинарный лог для конкретной базы. База маленькая, логи росли очень медленно. Проблема появилась только через 1.5 года. Я не стал сильно заморачиваться с этой темой, а просто решил ограничить максимальный размер файла бинарного лога (500мб) и время его хранения (3 дня). Для этого добавляем в файл конфигурации mysql /etc/my.cnf следующие параметры:
max_binlog_size= 500M expire_logs_days = 3
Добавляются в секцию [mysqld]. После этого mysql, или в моем случае mariadb надо перезапустить:
# systemctl restart mariadb
После перезапуска база сама почистит лог и уменьшит размер файлов mysql-bin, лишние при этом будут просто удалены. Если у вас нет репликации, то создание бинарных логов можно отключить, удалив все параметры, которые за них отвечают. У меня, к примеру, это:
log-bin = /var/lib/mysql/mysql-bin binlog-do-db = database
После этого перезапускаем базу. При ограничении размера и времени хранения бинарного лога, рекомендую настроить мониторинг mysql репликации, чтобы оперативно решать проблемы, которые возникают во время работы репликации. А они возникают и не так уж и редко.
Онлайн курс по Kubernetes
Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.Если вы ответите "да" хотя бы на один вопрос, то это ваш курс:
- устали тратить время на автоматизацию?
- хотите единообразные окружения?;
- хотите развиваться и использовать современные инструменты?
- небезразлична надежность инфраструктуры?
- приходится масштабировать инфраструктуру под растущие потребности бизнеса?
- хотите освободить продуктовые команды от части задач администрирования и автоматизации и сфокусировать их на развитии продукта?
после последнего обновления сервера и в частности пакета mysql бинарные логи стали разрастаться, до этого был один файл за 1.5 дня теперь 5-6 за один. понятное дело что можно как предложено в статье уменьшить время хранения логов но хотелось бы разобраться в причинах такого поведения.
Объем файлов напрямую зависит от интенсивности использования (изменений) в базе
У меня при записи "expire_logs_days" выдавалась ошибка конфигурации при попытке перезапустить mysql. Сработала "binlog_expire_logs_seconds"
Столкнулся с проблемой что не удаляются файлы binlog. Я уже делал настройку expire_logs_days на разных серверах и все было отлично – mysql чистил старые лог файлы, но она одном сервере это не работает. Никаких ошибок нигде нет, но старые binlog не удаляются хоть убейся. Конфиг /etc/mysql/mysql.cnf точно правильный, рестарт mysql разумеется делал – результата нет. Из консоли mysql команда ручной чистки работает PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 90 DAY) + INTERVAL 0 SECOND; Куда копать, ума не приложу(