5.2.4.2. Установка Двоичного Формата Журнала

Можно выбрать двоичный формат журналирования явно, запуская сервер MySQL с --binlog-format=type. Поддерживаемые значения для type :

STATEMENT журналирование причин, чтобы быть базируемым оператором.
ROW журналирование причин, чтобы быть базируемой строкой.
MIXED журналирование причин, чтобы использовать смешанный формат.

В MySQL 5.6 двоичный файл значения по умолчанию, регистрирующий формат, STATEMENT.

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

mysql> SET GLOBAL binlog_format = 'STATEMENT';mysql> SET GLOBAL binlog_format = 'ROW';mysql> SET GLOBAL binlog_format = 'MIXED';

Отдельный клиент может управлять форматом журналирования для его собственных операторов, устанавливая значение сеанса binlog_format:

mysql> SET SESSION binlog_format =
        'STATEMENT';mysql> SET SESSION binlog_format = 'ROW';mysql> SET SESSION binlog_format = 'MIXED';

Отметить

Каждый MySQL Server может установить свое собственное и только свой собственный двоичный формат журналирования (истина, ли binlog_format устанавливается с глобальной переменной или контекстом сеанса). Это означает, что изменение формата журналирования на ведущем устройстве репликации не заставляет ведомое устройство изменять свой формат журналирования, чтобы соответствовать. (При использовании STATEMENT режим, binlog_format системная переменная не тиражируется; при использовании MIXED или ROW регистрируя режим, это тиражируется, но игнорируется ведомым устройством.) Изменение двоичного журналирования форматирует на ведущем устройстве, в то время как репликация является продолжающейся, или также не изменяя это на ведомом устройстве может таким образом вызвать неожиданные результаты, или даже заставить репликацию перестать работать в целом.

Изменить глобальную переменную или сеанс binlog_format значение, Вы должны иметь SUPER полномочие.

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

Есть несколько причин, почему клиент мог бы хотеть установить двоичный файл, входящий в систему основание на сеанс:

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

Есть исключения, когда невозможно переключить формат репликации во времени выполнения:

Изнутри сохраненной функции или триггера
Если NDB механизм хранения включается
Если сеанс находится в настоящий момент в режиме построчной репликации и имеет открытые временные таблицы

Попытка переключить формат в любой из этих случаев приводит к ошибке.

Если Вы используете InnoDB таблицы и уровень изоляции транзакции READ COMMITTED или READ UNCOMMITTED, только основанное на строке журналирование может использоваться. Возможно изменить формат журналирования на STATEMENT, но выполнение так во времени выполнения приводит очень быстро к ошибкам потому что InnoDB больше не может выполнить вставляет.

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

С двоичным журналом форматируют набор к ROW, много изменений пишутся двоичному журналу, используя основанный на строке формат. Некоторые изменения, однако, все еще используют основанный на операторе формат. Примеры включают весь DDL (язык определения данных) операторы такой как CREATE TABLE, ALTER TABLE, или DROP TABLE.

--binlog-row-event-max-size опция доступна для серверов, которые способны к построчной репликации. Строки сохранены в двоичный файл, входят в систему блоки, имеющие размер в байтах, не превышающих значение этой опции. Значение должно быть кратным числом 256. Значение по умолчанию 1024.

Предупреждение

При использовании основанного на операторе журналирования для репликации для данных на ведущем устройстве и ведомом устройстве возможно стать отличающимся, если оператор разрабатывается таким способом, которым модификация данных недетерминирована; то есть, это оставляют желанию оптимизатора запросов. Вообще, это не хорошая практика даже за пределами репликации. Для подробного объяснения этой проблемы см. Раздел C.5.8, "Известные Проблемы в MySQL".

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