Двоичный журнал содержит «события», описывающие изменения в базе данных, такие как операции создания таблиц или изменения данных в таблицах. Он также содержит события для операторов, которые потенциально могли внести изменения (например, оператор 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 не следует удалять старые файлы двоичного журнала на источнике, пока не убедитесь, что ни одна реплика больше не нуждается в их использовании. Например, если ваши реплики никогда не отстают более чем на три дня, один раз в день вы можете выполнить 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.8, «Протоколирование двоичных хранимых программ».

Обратите внимание, что формат двоичного журнала в MySQL 9.2 отличается от предыдущих версий 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 9.2 поддержка 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. В этом случае двоичный журнал некорректен, и репликацию следует перезапустить с новой копии данных источника.

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