5.4.4.2 Настройка формата двоичного журнала
Вы можете явно выбрать формат двоичного протоколирования, запустив сервер MySQL с помощью --binlog-format=. Поддерживаемые значения для typetype следующие:
STATEMENTприводит к протоколированию на основе инструкций.ROWприводит к протоколированию на основе строк.MIXEDприводит к протоколированию в смешанном формате.
Настройка формата двоичного протоколирования не активирует двоичное протоколирование для сервера. Настройка вступает в силу только при включенном двоичном протоколировании на сервере, что происходит, когда системная переменная log_bin установлена в значение ON. В MySQL 5.7 двоичное протоколирование по умолчанию не включено, и вы включаете его, используя опцию --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 требует привилегий, достаточных для установки ограниченных системных переменных сеанса. См. Раздел 5.1.8.1, «Привилегии системных переменных».
Существует несколько причин, по которым клиент может захотеть установить двоичное протоколирование на уровне сеанса:
Сеанс, который делает много небольших изменений в базе данных, может использовать протоколирование на основе строк.
Сеанс, выполняющий обновления, которые соответствуют многим строкам в условии
WHERE, может использовать протоколирование на основе инструкций, поскольку протоколирование нескольких инструкций более эффективно, чем многих строк.Некоторые инструкции требуют много времени на выполнение на источнике, но приводят к изменению только нескольких строк. Поэтому может быть полезно реплицировать их с использованием протоколирования на основе строк.
Существуют исключения, когда вы не можете изменить формат репликации во время выполнения:
Изнутри хранимой функции или триггера.
Если включен движок хранения
NDB.Если сеанс в настоящее время находится в режиме репликации на основе строк и имеет открытые временные таблицы.
Попытка изменить формат в любом из этих случаев приводит к ошибке.
Изменение формата репликации во время выполнения не рекомендуется, когда существуют временные таблицы, потому что временные таблицы регистрируются только при использовании репликации на основе инструкций, в то время как при репликации на основе строк они не регистрируются. При смешанной репликации временные таблицы обычно регистрируются; исключения возникают при использовании загружаемых функций и функции UUID().
Изменение формата репликации во время выполнения репликации также может привести к проблемам. Каждый сервер 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 доступна для серверов, способных к репликации на основе строк. Строки хранятся в двоичном журнале в блоках размером не более значения этой опции в байтах. Значение должно быть кратно 256. Значение по умолчанию составляет 8192.
При использовании протоколирования на основе инструкций для репликации данные на источнике и реплике могут отличаться, если инструкция разработана таким образом, что изменение данных неопределённо; то есть, оно зависит от оптимизатора запросов. В целом, это не хорошая практика даже вне репликации. Подробное описание этой проблемы см. в Разделе B.3.7, «Известные проблемы в MySQL».
© 2025 Oracle
Licensed under the GPLv2 License.