7.4.4.2 Настройка формата двоичного журнала
Вы можете явно выбрать формат двоичного протоколирования, запустив сервер MySQL с параметром --binlog-format=. Поддерживаемые значения для typetype:
STATEMENTприводит к протоколированию на основе операторов.ROWприводит к протоколированию на основе строк. Это значение по умолчанию.MIXEDприводит к протоколированию в смешанном формате.
Настройка формата двоичного протоколирования не активирует двоичное протоколирование для сервера. Настройка вступает в силу только при включенном двоичном протоколировании на сервере, что имеет место, когда системная переменная log_bin установлена в значение ON. В MySQL 8.4 двоичное протоколирование включено по умолчанию и отключается только при запуске сервера с параметрами --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, «Права на системные переменные».
Существует несколько причин, по которым клиент может захотеть установить двоичное протоколирование на основе сессии:
Сессия, выполняющая много небольших изменений в базе данных, может захотеть использовать протоколирование на основе строк.
Сессия, выполняющая обновления, которые соответствуют многим строкам в условии
WHERE, может захотеть использовать протоколирование на основе операторов, потому что эффективнее протоколировать несколько операторов, чем много строк.Некоторые операторы требуют много времени выполнения на источнике, но приводят к изменению только нескольких строк. Поэтому может быть полезно их реплицировать с помощью протоколирования на основе строк.
Существуют исключения, когда невозможно переключить формат репликации во время работы:
Формат репликации нельзя изменить внутри хранимой функции или триггера.
Если включен движок хранилища
NDB.Если у сессии открыты временные таблицы, формат репликации для сессии нельзя изменить (
SET @@SESSION.binlog_format).Если у любого канала репликации открыты временные таблицы, формат репликации нельзя изменить глобально (
SET @@GLOBAL.binlog_formatилиSET @@PERSIST.binlog_format).Если какой-либо поток применяющего репликации находится в данный момент в работе, глобальный формат репликации нельзя изменить (
SET @@GLOBAL.binlog_formatилиSET @@PERSIST.binlog_format).
Попытка переключения формата репликации в любом из этих случаев (или попытка установить текущий формат репликации) приводит к ошибке. Однако вы можете использовать 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.
При использовании протоколирования на основе операторов для репликации возможно различие данных на источнике и реплике, если оператор спроектирован таким образом, что изменение данных является неопределенным; то есть оно зависит от оптимизатора запросов. В целом, это не лучшая практика даже вне репликации. Подробное описание этой проблемы см. в разделе B.3.7, «Известные проблемы в MySQL».
© 2025 Oracle
Licensed under the GPLv2 License.