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

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

Вы можете переключиться с протоколирования на основе операторов на протоколирование на основе строк во время выполнения, даже если временные таблицы были созданы, но вы не можете переключиться с протоколирования на основе строк или смешанного формата на протоколирование на основе операторов во время выполнения из-за возможных CREATE TEMPORARY TABLE операторов, которые были опушены из двоичного журнала в предыдущем режиме.

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

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

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

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

Чтение двоичного журнала. mysqlbinlog отображает события на основе строк в двоичном журнале, используя оператор BINLOG. Этот оператор отображает событие в виде строки, закодированной в формате Base64, смысл которой не очевиден. При вызове с параметрами --base64-output=DECODE-ROWS и --verbose, mysqlbinlog форматирует содержимое двоичного журнала для удобочитаемости. Когда события двоичного журнала были записаны в формате на основе строк, и вы хотите прочитать или восстановиться после сбоя репликации или базы данных, вы можете использовать эту команду для чтения содержимого двоичного журнала. Для получения дополнительной информации см. Раздел 6.6.9.2, «mysqlbinlog Отображение событий на основе строк».

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

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

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

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