Журналирование временных таблиц на основе строк. Как отмечается в разделе 16.4.1.29 «Репликация и временные таблицы», временные таблицы не реплицируются при использовании формата на основе строк. При использовании смешанного формата журналирования инструкции “safe”, связанные с временными таблицами, записываются в формате на основе инструкций. Дополнительную информацию см. в разделе 16.2.1.1 «Преимущества и недостатки репликации на основе инструкций и на основе строк».

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

Вы можете переключиться с формата двоичного лога на основе инструкций на формат на основе строк во время выполнения, даже если временные таблицы были созданы. Начиная с MySQL 5.7.25, MySQL-сервер отслеживает режим журналирования, который был активен при создании каждой временной таблицы. Когда сессия клиента завершается, сервер записывает инструкцию DROP TEMPORARY TABLE IF EXISTS для каждой временной таблицы, которая всё ещё существует и была создана при использовании двоичного лога на основе инструкций. Если двоичный лог в формате на основе строк или смешанном формате был активен при создании таблицы, инструкция DROP TEMPORARY TABLE IF EXISTS не регистрируется. В предыдущих выпусках инструкция DROP TEMPORARY TABLE IF EXISTS регистрировалась независимо от режима журналирования, который был активен.

Нетранзакционные операторы DML, включающие временные таблицы, разрешены при использовании binlog_format=ROW, при условии, что все нетранзакционные таблицы, затронутые операторами, являются временными таблицами (Ошибка #14272672).

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

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

Чтение двоичного журнала. mysqlbinlog отображает события на основе строк в двоичном журнале с помощью инструкции BINLOG (см. раздел 13.7.6.1 «Инструкция BINLOG»). Эта инструкция отображает событие как строку в кодировке base 64, смысл которой не очевиден. При вызове с параметрами --base64-output=DECODE-ROWS и --verbose mysqlbinlog форматирует содержимое двоичного журнала для удобочитаемости. Если события двоичного журнала были записаны в формате на основе строк, и вы хотите прочитать или восстановить после сбоя репликации или базы данных, вы можете использовать эту команду для чтения содержимого двоичного журнала. Дополнительную информацию см. в разделе 4.6.7.2 «Вывод событий на основе строк mysqlbinlog».

Ошибки выполнения двоичного журнала и режим выполнения реплики. Использование slave_exec_mode=IDEMPOTENT обычно полезно только при репликации MySQL NDB Cluster, для которой IDEMPOTENT является значением по умолчанию. (См. раздел 21.7.10 «Репликация NDB Cluster: двунаправленная и циклическая репликация»). Когда slave_exec_mode равно IDEMPOTENT, отказ в применении изменений из RBL, потому что исходная строка не найдена, не вызывает ошибку и не приводит к сбою репликации. Это означает, что возможно, что обновления не применяются на реплике, так что источник и реплика больше не синхронизированы. Проблемы задержки и использование нетранзакционных таблиц с RBR, когда slave_exec_mode равно IDEMPOTENT, могут привести к дальнейшему расхождению источника и реплики. Дополнительную информацию о slave_exec_mode см. в разделе 5.1.7 «Системные переменные сервера».

В других сценариях установка slave_exec_mode на значение STRICT обычно достаточно; это значение по умолчанию для движков хранения, отличных от NDB.

Фильтрование по идентификатору сервера не поддерживается. Вы можете фильтровать по идентификатору сервера, используя параметр IGNORE_SERVER_IDS для инструкции CHANGE MASTER TO. Этот параметр работает с форматами журналирования на основе инструкций и на основе строк. Другой метод фильтрации изменений на некоторых репликах заключается в использовании предложения WHERE, которое включает предложение @@server_id <> id_value с операторами UPDATE и DELETE. Например, WHERE @@server_id <> 1. Однако это не работает правильно с журналированием на основе строк. Чтобы использовать системную переменную server_id для фильтрации инструкций, используйте журналирование на основе инструкций.

RBL, нетранзакционные таблицы и остановленные реплики. При использовании журналирования на основе строк, если сервер реплики останавливается во время обновления репликационным потоком нетранзакционной таблицы, база данных реплики может перейти в несогласованное состояние. По этой причине рекомендуется использовать транзакционный движок хранения, такой как InnoDB, для всех таблиц, реплицированных с использованием формата на основе строк. Использование инструкций STOP SLAVE или STOP SLAVE SQL_THREAD перед выключением сервера реплики помогает предотвратить возникновение проблем и всегда рекомендуется независимо от используемого формата журнала или движка хранения.