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

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

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

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

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

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

Задержка и размер двоичного журнала. 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 реплики помогает предотвратить возникновение проблем и всегда рекомендуется независимо от используемого формата журналирования или движка хранения.