Двоичный журнал содержит «события», описывающие изменения в базе данных, такие как операции создания таблиц или изменения данных в таблицах. Он также содержит события для операторов, которые потенциально могли внести изменения (например, оператор DELETE, который не сопоставил ни одной строки), если не используется журналирование на основе строк. Двоичный журнал также содержит информацию о том, сколько времени занимал каждый оператор, обновлявший данные. Двоичный журнал имеет две важные цели:

Двоичный журнал не используется для операторов, таких как SELECT или SHOW, которые не изменяют данные. Для журналирования всех операторов (например, для определения проблемного запроса) используйте общий журнал запросов. См. Раздел 7.4.3, «Общий журнал запросов».

Запуск сервера с включённым двоичным журналированием несколько замедляет производительность. Однако преимущества двоичного журнала в настройке репликации и восстановлении операций обычно перевешивают это незначительное снижение производительности.

Двоичный журнал устойчив к непредвиденным остановкам. Записываются или считываются только полные события или транзакции.

Пароли в операторах, записанных в двоичный журнал, переписываются сервером, чтобы не появляться в явном тексте. См. также Раздел 8.1.2.3, «Пароли и журналирование».

Файлы двоичного журнала и релейные журналы MySQL могут быть зашифрованы, что помогает защитить эти файлы и потенциально конфиденциальные данные, содержащиеся в них, от злоупотреблений внешними злоумышленниками, а также от несанкционированного просмотра пользователями операционной системы, где они хранятся. Вы включаете шифрование на сервере MySQL, задав системную переменную binlog_encryption значение ON. Для получения дополнительной информации см. Раздел 19.3.2, «Шифрование файлов двоичного журнала и релейного журнала».

В данном обсуждении описаны некоторые параметры сервера и переменные, которые влияют на работу двоичного журналирования. Полный список см. в Разделе 19.1.6.4, «Параметры и переменные двоичного журналирования».

Двоичное журналирование включено по умолчанию (системная переменная log_bin установлена в ON). Исключением является случай, когда вы используете mysqld для ручного инициализации каталога данных, вызвав его с параметром --initialize или --initialize-insecure, когда двоичное журналирование отключено по умолчанию, но может быть включено путем указания параметра --log-bin.

Для отключения двоичного журналирования вы можете указать параметр --skip-log-bin или --disable-log-bin при запуске. Если любой из этих параметров указан и --log-bin также указан, имеет приоритет параметр, указанный позже.

Параметры --log-replica-updates и --replica-preserve-commit-order требуют включенного двоичного журналирования. Если вы отключаете двоичное журналирование, опустите эти параметры или укажите --log-replica-updates=OFF и --skip-replica-preserve-commit-order. MySQL отключает эти параметры по умолчанию, когда указан --skip-log-bin или --disable-log-bin. Если вы укажите --log-replica-updates или --replica-preserve-commit-order вместе с --skip-log-bin или --disable-log-bin, будет выдано предупреждение или сообщение об ошибке.

Параметр --log-bin[=base_name] используется для указания базового имени файлов двоичного журнала. Если вы не указываете параметр --log-bin, MySQL использует binlog в качестве базового имени файлов двоичного журнала по умолчанию. Для совместимости с более ранними версиями, если вы укажите параметр --log-bin без строки или с пустой строкой, имя по умолчанию будет host_name-bin, используя имя хоста машины. Рекомендуется указать имя, чтобы в случае изменения имени хоста вы могли легко продолжать использовать те же имена файлов двоичного журнала (см. Раздел B.3.7, «Известные проблемы MySQL»). Если вы укажете расширение в имени журнала (например, --log-bin=base_name.extension), расширение будет молча удалено и проигнорировано.

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

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

Для отслеживания использованных файлов двоичного журнала, mysqld также создаёт файл индекса двоичного журнала, который содержит имена файлов двоичного журнала. По умолчанию он имеет то же базовое имя, что и файл двоичного журнала, с расширением '.index'. Вы можете изменить имя файла индекса двоичного журнала с помощью параметра --log-bin-index[=file_name]. Не следует вручную редактировать этот файл во время работы mysqld, так как это может сбить с толку mysqld.

Термин «файл двоичного журнала» обычно обозначает отдельный пронумерованный файл, содержащий события базы данных. Термин «двоичный журнал» обозначает совокупность пронумерованных файлов двоичного журнала плюс файл индекса.

По умолчанию местоположение файлов двоичного журнала и файла индекса двоичного журнала — каталог данных. Вы можете использовать параметр --log-bin для указания альтернативного местоположения, добавив абсолютный путь к базовому имени для указания другого каталога. Когда сервер считывает запись из файла индекса двоичного журнала, который отслеживает используемые файлы двоичного журнала, он проверяет, содержит ли запись относительный путь. Если это так, относительная часть пути заменяется абсолютным путем, установленным с помощью параметра --log-bin. Абсолютный путь, записанный в файле индекса двоичного журнала, остаётся неизменным; в таком случае файл индекса должен быть отредактирован вручную, чтобы включить новые пути или пути. Имя базы файла двоичного журнала и любой указанный путь доступны как системная переменная log_bin_basename.

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

Клиент, имеющий достаточные привилегии для установки ограниченных системных переменных сеанса (см. Раздел 7.1.9.1, «Системные переменные привилегий»), может отключить двоичное протоколирование собственных операторов, используя оператор SET sql_log_bin=OFF.

По умолчанию сервер регистрирует длину события, а также само событие и использует это для проверки правильности записи события. Вы также можете заставить сервер записывать контрольные суммы для событий, установив системную переменную binlog_checksum. При чтении из двоичного журнала источник по умолчанию использует длину события, но может быть настроен на использование контрольных сумм, если они доступны, включив source_verify_checksum. Поток ввода/вывода репликации (получатель) на реплике также проверяет события, полученные от источника. Вы можете заставить поток репликации SQL (применитель) использовать контрольные суммы, если они доступны при чтении из файла журнала репликации, включив replica_sql_verify_checksum.

Формат событий, записанных в двоичном журнале, зависит от формата двоичного протоколирования. Поддерживаются три типа форматов: протоколирование на основе строк, протоколирование на основе операторов и смешанное протоколирование. Используемый формат двоичного протоколирования зависит от версии MySQL. Описания форматов протоколирования см. в Разделе 7.4.4.1, «Форматы двоичного протоколирования».

Сервер оценивает параметры --binlog-do-db и --binlog-ignore-db аналогично тому, как он оценивает параметры --replicate-do-db и --replicate-ignore-db. Сведения об этом см. в Разделе 19.2.5.1, «Оценка параметров репликации и двоичного протоколирования на уровне базы данных».

Реплика запускается с log_replica_updates, включенным по умолчанию, что означает, что реплика записывает в свой собственный двоичный журнал любые изменения данных, полученные от источника. Для работы этого параметра должен быть включен двоичный журнал (см. Раздел 19.1.6.3, «Параметры и переменные сервера реплики»). Этот параметр позволяет реплике выступать в качестве источника для других реплик.

Вы можете удалить все файлы двоичного журнала с помощью оператора RESET BINARY LOGS AND GTIDS или подмножество из них с помощью PURGE BINARY LOGS. См. Раздел 15.7.8.6, «Оператор RESET» и Раздел 15.4.1.1, «Оператор PURGE BINARY LOGS».

Если вы используете MySQL Replication, не удаляйте старые файлы двоичного журнала на источнике, пока не убедитесь, что ни одна реплика не нуждается в их использовании. Например, если ваши реплики никогда не отстают более чем на три дня, один раз в день вы можете выполнить mysqladmin flush-logs binary на источнике, а затем удалить все журналы, которым более трех дней. Вы можете удалить файлы вручную, но предпочтительнее использовать PURGE BINARY LOGS, который также безопасно обновляет для вас файл индекса двоичного журнала (и который может принимать аргумент даты). См. Раздел 15.4.1.1, «Оператор PURGE BINARY LOGS».

Вы можете просмотреть содержимое файлов двоичного журнала с помощью утилиты mysqlbinlog. Это может быть полезно, когда вы хотите повторно обработать операторы в журнале для операции восстановления. Например, вы можете обновить сервер MySQL из двоичного журнала следующим образом:

$> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog также может использоваться для отображения содержимого файла журнала репликации на реплике, поскольку они записываются в том же формате, что и файлы двоичного журнала. Дополнительную информацию об утилите mysqlbinlog и ее использовании см. в Разделе 6.6.9, «mysqlbinlog — Утилита для обработки файлов двоичного журнала». Более подробную информацию о двоичном журнале и операциях восстановления см. в Разделе 9.5, «Восстановление в определенное время (инкрементное)».

Двоичное протоколирование выполняется сразу после завершения оператора или транзакции, но до освобождения любых блокировок или выполнения любого подтверждения. Это гарантирует, что журнал записывается в порядке подтверждения.

Изменения в нетранзакционных таблицах сохраняются в двоичном журнале сразу после выполнения.

В рамках незавершенной транзакции все обновления (UPDATE, DELETE или INSERT), изменяющие транзакционные таблицы, такие как InnoDB таблицы, кэшируются до тех пор, пока сервер не получит оператор COMMIT. В этот момент mysqld записывает всю транзакцию в двоичный журнал до выполнения оператора COMMIT.

Изменения в нетранзакционных таблицах не могут быть отменены. Если транзакция, которая отменяется, включает изменения в нетранзакционных таблицах, вся транзакция регистрируется с оператором ROLLBACK в конце, чтобы гарантировать, что изменения в этих таблицах будут реплицированы.

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

Переменная состояния Binlog_cache_use показывает количество транзакций, которые использовали этот буфер (и, возможно, временный файл) для хранения операторов. Переменная состояния Binlog_cache_disk_use показывает, сколько из этих транзакций фактически пришлось использовать временный файл. Эти две переменные можно использовать для настройки binlog_cache_size до достаточно большого значения, чтобы избежать использования временных файлов.

Системная переменная max_binlog_cache_size (по умолчанию 4 ГБ, что также является максимальным значением) может использоваться для ограничения общего размера, используемого для кэширования транзакции с несколькими операторами. Если транзакция больше, чем это число байтов, она завершается ошибкой и отменяется. Минимальное значение равно 4096.

Если вы используете двоичный журнал и протоколирование на основе строк, одновременные вставки преобразуются в обычные вставки для операторов CREATE ... SELECT или INSERT ... SELECT. Это делается для того, чтобы вы могли воссоздать точную копию своих таблиц, применяя журнал во время операции резервного копирования. Если используется протоколирование на основе операторов, исходный оператор записывается в журнал.

Формат двоичного журнала имеет некоторые известные ограничения, которые могут повлиять на восстановление из резервных копий. См. Раздел 19.5.1, «Возможности и проблемы репликации».

Двоичное протоколирование для хранимых программ выполняется, как описано в Разделе 27.7, «Двоичное протоколирование хранимых программ».

Обратите внимание, что формат двоичного журнала в MySQL 8.4 отличается от предыдущих версий MySQL из-за улучшений в репликации. См. Раздел 19.5.2, «Совместимость репликации между версиями MySQL».

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

По умолчанию, двоичный журнал синхронизируется с диском при каждом записи (sync_binlog=1). Если sync_binlog не был включен, и операционная система или машина (а не только сервер MySQL) потерпела сбой, существует вероятность потери последних операторов двоичного журнала. Чтобы предотвратить это, включите переменную системы sync_binlog для синхронизации двоичного журнала с диском после каждой N группы команд подтверждения. См. Раздел 7.1.8, «Переменные системы сервера». Наиболее безопасное значение для sync_binlog — 1 (по умолчанию), но это также самое медленное.

В более ранних выпусках MySQL существовала возможность несоответствия между содержимым таблицы и содержимым двоичного журнала в случае сбоя, даже если sync_binlog было установлено в 1. Например, если вы используете InnoDB таблицы и сервер MySQL обрабатывает оператор COMMIT, он записывает много подготовленных транзакций в двоичный журнал последовательно, синхронизирует двоичный журнал, а затем подтверждает транзакцию в InnoDB. Если сервер неожиданно завершил работу между этими двумя операциями, транзакция будет отменена InnoDB при перезапуске, но всё ещё будет существовать в двоичном журнале. Эта проблема была решена в предыдущих версиях путём включения поддержки InnoDB двухфазного подтверждения в транзакциях XA. В MySQL 8.4 поддержка InnoDB двухфазного подтверждения в транзакциях XA всегда включена.

Поддержка InnoDB двухфазного подтверждения в транзакциях XA гарантирует синхронизацию двоичного журнала и файлов данных InnoDB. Однако сервер MySQL также должен быть настроен на синхронизацию двоичного журнала и журналов InnoDB с диском перед подтверждением транзакции. Журналы InnoDB синхронизируются по умолчанию, а sync_binlog=1 гарантирует синхронизацию двоичного журнала. Влияние неявной поддержки InnoDB двухфазного подтверждения в транзакциях XA и sync_binlog=1 заключается в том, что при перезапуске после сбоя, после отмены транзакций, сервер MySQL сканирует последний файл двоичного журнала, чтобы собрать значения транзакций xid и вычислить последнюю допустимую позицию в файле двоичного журнала. Затем сервер MySQL сообщает InnoDB о завершении любых подготовленных транзакций, успешно записанных в двоичный журнал, и обрезает двоичный журнал до последней допустимой позиции. Это гарантирует, что двоичный журнал отражает точные данные InnoDB таблиц, и, следовательно, реплика остаётся синхронизированной с источником, так как она не получает оператор, который был отменён.

Если сервер MySQL обнаруживает во время восстановления после сбоя, что двоичный журнал короче, чем должен был быть, ему не хватает по крайней мере одной успешно подтверждённой InnoDB транзакции. Этого не должно произойти, если sync_binlog=1 и файловая система выполняют фактическую синхронизацию при запросе (некоторые не делают), поэтому сервер выводит сообщение об ошибке The binary log file_name is shorter than its expected size. В этом случае этот двоичный журнал некорректен, и репликацию следует перезапустить со свежей копии данных источника.

Значения сеансов следующих системных переменных записываются в двоичный журнал и учитываются репликой при анализе двоичного журнала: