MySQL и MariaDB LinuxMySQL 8.0/8.4Percona Server 8.0/8.4

MySQL: бинарные журналы заполнили диск

  • Обновлено
  • Чтение ≈ 4 минуты

Краткий ответ

Правильный порядок: выяснить фактические файлы и период хранения, определить самую отстающую и отключённые реплики, проверить цепочку резервных копий, только затем согласовать удаление старых записей серверной SQL-командой.

В этой статье
  1. Что означает неисправность и в каких условиях возникает
  2. Возможные причины: как различить
  3. Пошаговая диагностика и устранение
  4. Как проверить исправление и что делать, если оно не помогло

#Что означает неисправность и в каких условиях возникает

В каталоге MySQL быстро увеличивается общий размер файлов бинарного журнала (например, binlog.000123), свободное место заканчивается и запись может остановиться. Бинарный журнал нужен для репликации и восстановления до момента времени, поэтому его нельзя удалять файловым менеджером. Правильный порядок: выяснить фактические файлы и период хранения, определить самую отстающую и отключённые реплики, проверить цепочку резервных копий, только затем согласовать удаление старых записей серверной SQL-командой.

#Возможные причины: как различить

Возможная причинаКак узнатьЧто делать
Отключённая или отстающая репликаРеплике нужны старые события, которые нельзя пока удалять.На реплике Source_Log_File указывает на ранний журнал либо IO не подключается.Восстановить чтение с реплики или продлить хранение.
Истёк срок уборки либо политика не заданаСрок хранения слишком большой для доступного диска, автоматическая очистка не срабатывает.SHOW BINARY LOGS содержит длинную историю, правила хранения не согласованы.Задать обоснованную политику по RPO и потребностям репликации.
Необычно большой объём записейМассовые изменения или миграция создают много событий binlog.Рост совпадает с загрузкой большого набора строк или операцией ETL.Сопоставить нагрузку и резервные копии, спланировать место.

#Пошаговая диагностика и устранение

  1. Остановите опасные действия и сообщите о рискеПри минимальном свободном месте свяжитесь с ответственным DBA, сообщите filesystem, процент использования и имя экземпляра. Не выполняйте rm, truncate, RESET BINARY LOGS AND GTIDS или перезапуск службы наугад: это может нарушить репликацию и восстановление. Если есть безопасный альтернативный том, администратор может временно освободить место за счёт несвязанных файлов по обычному регламенту.
  2. Подтвердите, что место занимают именно binlogПо SSH выполните df -h для раздела с datadir. В mysql на источнике запросите SHOW VARIABLES LIKE 'log_bin_basename';, SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; и SHOW BINARY LOGS;. Это покажет настроенный путь, срок и текущий список журналов. Не путайте с relay logs реплики и файлами общего табличного пространства.
  3. Сохраните контрольные сведения и проверку копийУточните, какая резервная копия полная и какие журналы требуются для восстановления после неё. Проверьте, что хотя бы одна копия физически доступна и метод восстановления документирован. Без подтверждения сохранности цепочки резервных копий нельзя выбирать дату очистки только по возрасту файлов.
  4. Проверьте все реплики, включая временно отключённыеПодключитесь к КАЖДОЙ реплике и выполните SHOW REPLICA STATUS\G. Запишите Source_Log_File, Read_Source_Log_Pos, Replica_IO_Running и ошибки, проверяя нужный канал. Если реплика отключена, её позиция может быть старой; без её учёта PURGE способен удалить необходимые события, и после подключения реплика не восстановит работу автоматически.
  5. Определите безопасную границу по самой отстающей репликеСравните файлы в SHOW BINARY LOGS источника с первым ещё нужным каждой реплике. Учитывайте и цепочку восстановления до момента времени (PITR). Нельзя выбирать PURGE TO по позиции самой быстрой реплики или просто по числу файлов; согласуйте у DBA самый ранний файл, необходимый хоть одной системе.
  6. Подготовьте команду, но не выполняйте с примерным именемПосле документированного согласования администратор формирует PURGE BINARY LOGS TO 'имя_проверенного_файла'; или BEFORE с проверенным временем. Команда TO удаляет файлы РАНЬШЕ указанного, но не сам указанный файл. Фиктивный маркер заменяется реальным файлом из SHOW BINARY LOGS только после проверок; не вводите эту строку напрямую из статьи на рабочем сервере.
  7. Проверяйте освобождённое место и репликациюПосле согласованной уборки снова выполните SHOW BINARY LOGS и df -h, затем на репликах SHOW REPLICA STATUS. Если очистка не удалила нужный объём, не удаляйте файлы в обход сервера: возможно, журнал ещё используется активной репликой. Если появились ошибки чтения binlog, остановите дальнейшие изменения и восстановите требуемую цепочку по процедуре DBA.
  8. Настройте долговременную политику храненияВместе с владельцем резервных копий определите период хранения исходя из допустимого отставания реплик и срока восстановления, а не выбирайте минимальное число наугад. Проверяйте через SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; действующее значение, сопоставляйте с политикой резервирования и доступным местом; изменение конфигурации и его откат оформите через управление настройками сервера.
  9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1Информационные SQL-запросы на источнике.
    SQLКоманда
    Информационные SQL-запросы на источнике. Нужны достаточные права; не удаляют журналы.
    SHOW VARIABLES LIKE 'log_bin_basename';
    SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
    SHOW BINARY LOGS;
    Вариант 2Читать статус на каждой реплике до любых удалений.
    SQLКоманда
    Читать статус на каждой реплике до любых удалений. Для MySQL 8.4 — REPLICATION CLIENT.
    SHOW REPLICA STATUS\G
    Вариант 3ОБРАЗЕЦ, не команда к непосредственному выполнению: выполняет только DBA после проверки всех реплик, PITR и…
    SQL
    ОБРАЗЕЦ, не команда к непосредственному выполнению: выполняет только DBA после проверки всех реплик, PITR и резервных копий. Удаляет журналы, предшествующие указанному.
    PURGE BINARY LOGS TO 'ИМЯ_ПРОВЕРЕННОГО_ФАЙЛА';

#Как проверить исправление и что делать, если оно не помогло

Успех — свободного места достаточно, требуемые файлы остались доступны, у всех реплик оба потока Yes, нет Last_IO_Error, а контрольное восстановление по утверждённой политике возможно. Если свободного места мало даже после безопасной очистки, расширяйте хранилище и разбирайте объём изменений вместо удаления нужных журналов.

Так эту ошибку тоже называют

MySQL: ERROR 1045 (28000) Access denied for user — причины и решение Проверьте пароль, хост пользователя и привилегии. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS MySQL: ERROR 2002 — Can't connect through socket — причины и решение Запустите mysqld и проверьте путь сокета. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS 1045 MySQL ERROR 1045 (28000): Access denied for user — как исправить `ERROR 1045 (28000): Access denied for user` значит, что сервер MySQL отклонил вход: неверный пароль, пользователь не существует для этого хоста, у него нет прав или исп… Программирование и базы данных MySQL и MariaDB MySQLMariaDB 1064 MySQL: ERROR 1064 — You have an error in your SQL syntax — причины и решение Ошибка 1064 — синтаксическая ошибка в запросе. Ниже — причины и порядок действий от простого к сложному. Программирование и базы данных MySQL и MariaDB LinuxWindows 1146 MySQL: ERROR 1146 — Table doesn't exist — причины и решение Таблица не найдена: неверная база, регистр имени в Linux или не применены миграции. Проверьте USE и SHOW TABLES. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.