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

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

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

Двоичный журнал, как правило, устойчив к непредвиденным остановкам, так как в журнал записываются или считываются только завершенные транзакции. Дополнительную информацию см. в Разделе 16.3.2, «Обработка неожиданной остановки реплики».

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

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

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

Если в имени файла журнала указано расширение (например, --log-bin=base_name.extension), расширение будет проигнорировано.

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

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

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

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

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

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

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

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

Реплика по умолчанию не записывает в свой собственный двоичный журнал никакие изменения данных, полученные от источника. Чтобы записать эти изменения, запустите реплику с параметром --log-slave-updates в дополнение к параметру --log-bin (см. Раздел 16.1.6.3, «Параметры и переменные сервера реплики»). Это выполняется, когда реплика также должна действовать как источник для других реплик в цепочной репликации.

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

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

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

$> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog также может использоваться для отображения содержимого файлов журнала репликации, так как они записываются в том же формате, что и файлы бинарного журнала. Для получения дополнительной информации об утилите mysqlbinlog и о том, как ее использовать, см. Раздел 4.6.7, «mysqlbinlog — Утилита для обработки файлов бинарного журнала». Для получения дополнительной информации о бинарном журнале и операциях восстановления см. Раздел 7.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 операторов. Это делается для того, чтобы вы могли воссоздать точную копию ваших таблиц, применяя журнал во время операции резервного копирования. Если вы используете журналирование на основе операторов, исходный оператор записывается в журнал.

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

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

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

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

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

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

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

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