16.1.2.2. Использование Основанного на строке Журналирования и Репликации

РУБЛЬ, RBR, и временные таблицы. Как отмечено в Разделе 16.4.1.22, "Репликация и Временные таблицы", временные таблицы не тиражируются при использовании основанного на строке формата. Когда смешанный формат в действительности, "безопасные" операторы, включающие временные таблицы, регистрируются, используя основанный на операторе формат. Для получения дополнительной информации см. Раздел 16.1.2.1, "Преимущества и Недостатки Основанной на операторе и Построчной репликации".

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

В MySQL 5.7 можно переключиться от основанного на операторе до основанного на строке двоичного режима журналирования, даже когда временные таблицы были созданы. Однако, используя основанный на строке формат, сервер MySQL не может определить режим журналирования, который был в действительности, когда данная временная таблица создавалась. Поэтому сервер в таких случаях регистрирует a DROP TEMPORARY TABLE IF EXISTS оператор для каждой временной таблицы, которая все еще существует для данного клиентского сеанса, когда тот сеанс заканчивается. В то время как это означает, что возможно что ненужное DROP TEMPORARY TABLE оператор мог бы быть зарегистрирован в некоторых случаях, оператор безопасен, и не вызывает ошибку, даже если таблица не существует, из-за присутствия IF NOT EXISTS опция.

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

РУБЛЬ и синхронизация нетранзакционных таблиц. Когда на многие строки влияют, набор изменений разделяется на несколько событий; когда оператор фиксирует, все эти события пишутся двоичному журналу. Выполняясь на ведомом устройстве, блокировка таблицы берется на всех таблицах, включенных, и затем строки применяются в пакетном режиме. (Это может или, возможно, не эффективно, в зависимости от механизма, используемого для копии ведомого устройства таблицы.)

Задержка и двоичный размер журнала. Поскольку изменения записей РУБЛЯ для каждой строки к двоичному журналу, его размер может увеличиться вполне быстро. В среде репликации это может значительно увеличить время, требуемое производить изменения на ведомом устройстве, которые соответствуют тем на ведущем устройстве. Следует знать о потенциале для этой задержки Ваших приложений.

Чтение двоичного журнала. mysqlbinlog выводит на экран основанные на строке события в двоичном журнале, используя BINLOG оператор (см. Раздел 13.7.6.1,"BINLOG Синтаксис"). Этот оператор выводит на экран событие в печатаемой форме, но как основа 64 закодированная строка, значение которой не очевидно. Когда вызвано с --base64-output=DECODE-ROWS и --verbose опции, mysqlbinlog форматирует содержание двоичного файла, входят в систему способ, который легко удобочитаем. Это полезно, когда двоичные события журнала были записаны в основанном на строке формате, если Вы хотите читать или восстановиться с репликации или отказа базы данных, используя содержание двоичного журнала. Для получения дополнительной информации см. Раздел 4.6.8.2, "mysqlbinlog Дисплей События Строки".

Двоичные ошибки выполнения журнала и slave_exec_mode. Если slave_exec_mode IDEMPOTENT, отказ применить изменения от РУБЛЯ, потому что исходная строка не может быть найдена, не инициировал ошибку или заставляет репликацию перестать работать. Это означает, что возможно, что обновления не применяются на ведомое устройство, так, чтобы ведущее устройство и ведомое устройство больше не синхронизировались. Проблемы задержки и использование нетранзакционных таблиц с RBR, когда slave_exec_mode IDEMPOTENT может заставить ведущее устройство и ведомое устройство отклоняться еще далее. Для получения дополнительной информации о slave_exec_mode, см. Раздел 5.1.4, "Системные Переменные Сервера".

Нехватка двоичных контрольных сумм журнала. РУБЛЬ не использует контрольных сумм. Это означает, что сеть, диск, и другие ошибки не могут быть идентифицированы, обрабатывая двоичный журнал. Чтобы гарантировать, что данные передаются без сетевого повреждения, можно хотеть рассмотреть использование SSL, который добавляет другой уровень вычисления контрольной суммы для соединений репликации. CHANGE MASTER TO у оператора есть опции, чтобы включить репликации по SSL. См. также Раздел 13.4.2.1,"CHANGE MASTER TO Синтаксис", для общей информации об установке MySQL с SSL.

Фильтрация основанного на ID сервера, не поддерживаемом. Обычная практика должна отфильтровать изменения на некоторых ведомых устройствах при использовании a WHERE пункт, который включает отношение @@server_id <> id_value пункт с UPDATE и DELETE операторы, простой пример такого пункта быть WHERE @@server_id <> 1. Однако, это не работает правильно с основанным на строке журналированием. Если следует использовать server_id системная переменная для фильтрации оператора, следует также использовать --binlog_format=STATEMENT.

В MySQL 5.7 можно сделать фильтрацию, основанную на ID сервера при использовании IGNORE_SERVER_IDS опция для CHANGE MASTER TO оператор. Эта опция работает с основанными на операторе и основанными на строке форматами журналирования.

Опции репликации на уровне базы данных. Эффекты --replicate-do-db, --replicate-ignore-db, и --replicate-rewrite-db опции отличаются значительно в зависимости от, или основанное на строке или основанное на операторе журналирование используется. Из-за этого рекомендуется избежать опций на уровне базы данных и вместо этого использовать опции на уровне таблицы такой как --replicate-do-table и --replicate-ignore-table. Для получения дополнительной информации об этих опциях и влиянии, которое Ваш выбор формата репликации оказывает на то, как они работают, см. Раздел 16.1.4, "Репликация и Двоичные Опции Журналирования и Переменные".

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

Использование STOP SLAVE или STOP SLAVE SQL_THREAD до завершения работы ведомого сервера MySQL помогает препятствовать тому, чтобы такие проблемы произошли, и всегда рекомендуется независимо от формата журналирования или используемых механизмов хранения.