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

Настройка формата двоичного протоколирования не активирует двоичное протоколирование для сервера. Настройка вступает в силу только при включенном двоичном протоколировании на сервере, что происходит, когда системная переменная log_bin установлена в значение ON. В MySQL 9.2 двоичное протоколирование включено по умолчанию и отключено только в том случае, если вы запустили сервер с --skip-log-bin или --disable-log-bin.

Формат протоколирования также можно изменить во время выполнения, хотя следует отметить, что есть ряд ситуаций, в которых это невозможно, как обсуждается позже в этом разделе. Установите глобальное значение системной переменной 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';

Изменение глобального значения binlog_format требует привилегий, достаточных для изменения глобальных системных переменных. Изменение значения сессии binlog_format требует привилегий, достаточных для изменения ограниченных переменных сессии. См. Раздел 7.1.9.1, «Привилегии системных переменных».

Есть несколько причин, по которым клиент может захотеть установить двоичное протоколирование на основе сессии:

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

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

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

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

Репликатор не может преобразовать записи двоичного журнала, полученные в формате протоколирования ROW, в формат STATEMENT для использования в собственном двоичном журнале. Следовательно, репликатор должен использовать формат ROW или MIXED, если используется источник. Изменение формата двоичного протоколирования на источнике с STATEMENT на ROW или MIXED во время репликации репликатору с форматом STATEMENT может привести к сбою репликации с ошибками, такими как Ошибка выполнения события строки: 'Невозможно выполнить оператор: невозможно записать в двоичный журнал, так как оператор в формате строк, а BINLOG_FORMAT = STATEMENT.'. Изменение формата двоичного протоколирования на репликаторе на формат STATEMENT, когда источник по-прежнему использует формат MIXED или ROW, также приводит к тому же типу сбоя репликации. Чтобы безопасно изменить формат, необходимо остановить репликацию и убедиться, что то же изменение выполнено как на источнике, так и на репликаторе.

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

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

При использовании протоколирования двоичного журнала на основе строк системная переменная binlog_row_event_max_size и соответствующий параметр запуска --binlog-row-event-max-size устанавливают ограничение на максимальный размер событий строк. Значение по умолчанию равно 8192 байта, и значение может быть изменено только при запуске сервера. При возможности строки, хранящиеся в двоичном журнале, группируются в события размером не более значения этого параметра. Если событие не может быть разделено, максимальный размер может быть превышен.

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