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

Двоичный журнал не используется для операторов такой как SELECT или SHOW это не изменяет данные. Зарегистрировать все операторы (например, чтобы идентифицировать проблемный запрос), используют общий журнал запросов. См. Раздел 5.2.3, "Общий Журнал запросов".

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

Начинаясь с MySQL 5.6.2, двоичный журнал безопасен от катастрофического отказа. Только полные события или транзакции регистрируются или читают назад.

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

Следующее обсуждение описывает некоторые из параметров сервера и переменных, которые влияют на работу двоичного журналирования. Для полного списка см. Раздел 16.1.4.4, "Двоичные Опции Журнала и Переменные".

Чтобы включить двоичному журналу, запустите сервер с --log-bin[=base_name] опция. Если нет base_name значение дается, имя по умолчанию является значением pid-file опция (который по умолчанию является именем хост-машины), сопровождаемый -bin. Если базовое имя дается, сервер пишет файл в каталоге данных, если базовое имя не дается с ведущим абсолютным путем, чтобы определить различный каталог. Рекомендуется, чтобы Вы определили базовое имя явно вместо того, чтобы использовать значение по умолчанию имени хоста; см. Раздел C.5.8, "Известные Проблемы в MySQL", по причине.

Если Вы предоставляете расширение на имя журнала (например, --log-bin=base_name.extension), расширение тихо удаляется и игнорируется.

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

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

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

Клиент, который имеет SUPER полномочие может отключить двоичное журналирование своих собственных операторов при использовании a SET sql_log_bin=0 оператор. См. Раздел 5.1.4, "Системные Переменные Сервера".

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

Формат событий, записанных в двоичном журнале, зависит от двоичного формата журналирования. Три типа формата поддерживаются, основанное на строке журналирование, основанное на операторе журналирование и смешано-основное журналирование. Двоичный используемый формат журналирования зависит от версии MySQL. Для общих описаний форматов журналирования см. Раздел 5.2.4.1, "Двоичные Форматы Журналирования". Для получения дальнейшей информации о формате двоичного журнала, см. MySQL Internals: Двоичный Журнал.

Сервер оценивает --binlog-do-db и --binlog-ignore-db опции таким же образом, как это делает --replicate-do-db и --replicate-ignore-db опции. Для получения информации о том, как это делается, см. Раздел 16.2.3.1, "Оценка Репликации На уровне базы данных и Двоичных Опций Журналирования".

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

Можно удалить все двоичные файлы журнала с RESET MASTER оператор, или подмножество их с PURGE BINARY LOGS. См. Раздел 13.7.6.6,"RESET Синтаксис", и Раздел 13.4.1.1,"PURGE BINARY LOGS Синтаксис".

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

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

shell> mysqlbinlog log_file
        | mysql -h server_name

mysqlbinlog также может использоваться, чтобы вывести на экран ведомое устройство репликации релейное содержание файла журнала, потому что они пишутся, используя тот же самый формат в качестве двоичных файлов журнала. Для получения дополнительной информации по mysqlbinlog утилите и как использовать это, см. Раздел 4.6.8, "mysqlbinlog — Утилита для Обработки Двоичных Файлов журнала" . Для получения дополнительной информации о двоичном журнале и операциях восстановления, см. Раздел 7.5, "Момент времени (Инкрементное) Восстановление Используя Двоичный Журнал".

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

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

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

Модификации к нетранзакционным таблицам не могут откатываться. Если транзакция, которая откатывается, включает модификации в нетранзакционные таблицы, вся транзакция регистрируется с a 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, "Функции репликации и Проблемы".

Двоичное журналирование для сохраненных программ делается как описано в Разделе 19.7, "Двоичное Журналирование Сохраненных Программ".

Отметьте, что двоичный формат журнала отличается по MySQL 5.6 от предыдущих версий MySQL, из-за улучшений в репликации. См. Раздел 16.4.2, "Версии MySQL Replication Compatibility Between".

Записи к двоичному файлу журнала и двоичному индексному файлу журнала обрабатываются таким же образом как записи к MyISAM таблицы. См. Раздел C.5.4.3, "Как MySQL Handles a Full Disk".

По умолчанию двоичный журнал не синхронизируется с диском в каждой записи. Так, если операционная система или машина (не только сервер MySQL) катастрофические отказы, есть шанс, что последние операторы двоичного журнала теряются. Чтобы предотвратить это, можно заставить двоичный журнал синхронизироваться с диском после каждого N записи к двоичному журналу, с sync_binlog системная переменная. См. Раздел 5.1.4, "Системные Переменные Сервера". 1 самое безопасное значение для sync_binlog, но также и самое медленное. Даже с sync_binlog набор к 1, есть все еще шанс несогласованности между табличным контентом и двоичным контентом журнала в случае катастрофического отказа. Например, если Вы используете InnoDB таблицы и серверные процессы MySQL a COMMIT оператор, это пишет целую транзакцию в двоичный журнал и затем фиксирует эту транзакцию в InnoDB. Если катастрофические отказы сервера между теми двумя операциями, транзакция откатывается InnoDB в перезапуске, но все еще существует в двоичном журнале. Чтобы разрешить это, следует установить --innodb_support_xa к 1. Хотя эта опция связывается с поддержкой транзакций XA в InnoDB, это также гарантирует, что двоичный журнал и файлы данных InnoDB синхронизируются.

Для этой опции, чтобы обеспечить больший запас прочности, сервер MySQL должен также быть сконфигурирован, чтобы синхронизировать двоичный журнал и InnoDB журналы к диску прежде, чем фиксировать транзакцию. InnoDB журналы синхронизируются по умолчанию, и sync_binlog=1 может использоваться, чтобы синхронизировать двоичный журнал. Эффект этой опции состоит в том что в перезапуске после катастрофического отказа, после выполнения отката транзакций, откатываемых сокращений сервера MySQL InnoDB транзакции от двоичного журнала. Это гарантирует, что двоичный журнал отражает точные данные InnoDB таблицы, и таким образом, что ведомое устройство остается в синхронии с ведущим устройством (не получение оператора, который откатывался).

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

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