Использование и обслуживание двоичного журнала

См. Обзор двоичного журнала для общего обзора двоичного журнала и Активация двоичного журнала для того, чтобы убедиться, что он работает на вашей системе.

Подробности об использовании двоичного журнала для репликации см. в разделе Репликация.

Удаление файлов журнала

Чтобы удалить все файлы двоичного журнала на сервере, выполните команду RESET MASTER. Чтобы удалить все двоичные журналы до определенной даты и времени или до определенного числа, используйте PURGE BINARY LOGS.

Файлы журналов также можно удалять автоматически с помощью системной переменной expire_logs_days. По умолчанию она установлена в 0 (удаление не происходит), но может быть установлена в количество дней, по истечении которых файл двоичного журнала будет автоматически удален. Файлы журналов будут проверяться на соответствие условию старше expire_logs_days только при вращении журнала, поэтому, если ваш двоичный журнал заполняется медленно и не достигает max_binlog_size ежедневно, вы можете увидеть, что более старые файлы журналов всё ещё сохраняются. Вы также можете принудительно выполнить вращение журнала и, соответственно, удаление по истечении срока действия, выполнив FLUSH BINARY LOGS регулярно. Всегда устанавливайте значение expire_logs_days выше, чем возможная задержка репликации.

Начиная с MariaDB 10.6, переменная binlog_expire_logs_seconds позволяет более точно управлять удалением двоичных логов и имеет приоритет, если обе переменные отличны от нуля.

Примеры

PURGE BINARY LOGS TO 'mariadb-bin.000063';

PURGE BINARY LOGS BEFORE '2013-04-22 09:55:22';

Безопасное удаление файлов двоичного журнала во время репликации

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

• Получите список файлов двоичного журнала на первичном сервере, выполнив SHOW BINARY LOGS.
• Перейдите на каждый сервер репликации и выполните SHOW SLAVE STATUS, чтобы проверить, какой файл двоичного журнала в данный момент читает каждая реплика.
• Найдите самый ранний файл журнала, который все еще читается репликой. Файлы журналов, предшествующие этому файлу, не понадобятся.
• При желании создайте резервную копию файлов журналов, которые будут удалены.
• Удалите все файлы журналов до (не включая) файла, определенного выше.

Формат двоичного журнала

Существует три формата двоичного журнала. По умолчанию используется протоколирование на основе инструкций, но также возможны протоколирование на основе строк и смешанный формат. Подробное обсуждение см. в разделе Форматы двоичных журналов.

Выборочное протоколирование в двоичный журнал

По умолчанию все изменения данных или структуры данных протоколируются. Это поведение можно изменить, запустив сервер с параметрами --binlog-ignore-db=database_name или --binlog-do-db=database_name параметры.

--binlog-ignore-db=database_name определяет базу данных для игнорирования в целях протоколирования, а --binlog-do-db=database_name не будет протоколировать какие-либо инструкции, если они не применяются к указанной базе данных.

--binlog-ignore-db=database_name ведёт себя по-разному в зависимости от того, используется ли протоколирование на основе инструкций или на основе строк. При протоколировании на основе инструкций сервер не будет протоколировать ни одну инструкцию, где база данных по умолчанию является database_name. База данных по умолчанию устанавливается с помощью инструкции USE.

Аналогично, --binlog-do-db=database_name ведет себя по-разному в зависимости от того, используется ли протоколирование на основе инструкций или на основе строк.

При протоколировании на основе инструкций сервер будет протоколировать только те инструкции, где база данных по умолчанию является database_name. База данных по умолчанию устанавливается с помощью инструкции USE.

При протоколировании на основе строк сервер будет протоколировать любые обновления любых таблиц в указанной базе данных/базах данных, независимо от текущей базы данных.

Примеры

Предположим, сервер был запущен с параметром --binlog-ignore-db=employees. Следующий пример будет протоколирован при использовании протоколирования на основе инструкций и не будет протоколирован при использовании протоколирования на основе строк.

USE customers;
UPDATE employees.details SET bonus=bonus*1.2;

Это происходит потому, что протоколирование на основе инструкций проверяет базу данных по умолчанию, в данном случае customers. Поскольку customers не указано в списке игнорируемых, инструкция будет протоколирована. При использовании протоколирования на основе строк пример не будет протоколирован, так как обновления записываются в таблицы в базе данных employees.

Предположим вместо этого, что сервер был запущен с параметром --binlog-do-db=employees. Следующий пример не будет протоколирован при использовании протоколирования на основе инструкций и будет протоколирован при использовании протоколирования на основе строк.

USE customers;
UPDATE employees.details SET bonus=bonus*1.2;

Это снова происходит потому, что протоколирование на основе инструкций проверяет базу данных по умолчанию, в данном случае customers. Поскольку customers не указано в списке включаемых, инструкция не будет протоколирована. При использовании протоколирования на основе строк пример будет протоколирован, так как обновления записываются в таблицы в базе данных employees.

Последствия ошибок заполнения диска на двоичное протоколирование

Если MariaDB столкнется с ошибкой заполнения диска при попытке записи в файл двоичного журнала, он будет продолжать попытки записи каждые 60 секунд. Сообщения журнала будут записываться в журнал ошибок каждые 600 секунд. Например:

2018-11-27  2:46:46 140278181563136 [Warning] mysqld: Disk is full writing '/var/lib/mariadb-bin.00001' (Errcode: 28 "No space left on device"). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
2018-11-27  2:46:46 140278181563136 [Warning] mysqld: Retry in 60 secs. Message reprinted in 600 secs

Однако, если MariaDB столкнется с ошибкой заполнения диска при попытке открыть новый файл двоичного журнала, он полностью отключит двоичное протоколирование. Сообщение об ошибке, подобное следующему, будет записано в журнал ошибок:

2018-11-27  3:30:49 140278181563136 [ERROR] Could not open '/var/lib/mariadb-bin.00002 for logging (error 28). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
2018-11-27  3:30:49 140278181563136 [ERROR] mysqld: Error writing file '(null)' (errno: 9 "Bad file descriptor")
2018-11-27  3:30:49 140278181563136 [ERROR] mysqld: Error writing file '(null)' (errno: 28 "No space left on device")

См. также

• ОЧИСТКА ЖУРНАЛОВ