Spec-Zone .ru
спецификации, руководства, описания, API

16.4.1.33. Репликация и Переменные

Системные переменные не тиражируются правильно при использовании STATEMENT режим, за исключением следующих переменных, когда они используются с контекстом сеанса:

Когда MIXED режим используется, переменные в предыдущем списке, когда использующийся с контекстом сеанса, вызывают переключатель от основанного на операторе до основанного на строке журналирования. См. Раздел 5.2.4.3, "Смешанный Двоичный Формат Журналирования".

sql_mode также тиражируется за исключением NO_DIR_IN_CREATE режим; ведомое устройство всегда сохраняет свое собственное значение для NO_DIR_IN_CREATE, независимо от изменений к этому на ведущем устройстве. Это - истина для всех форматов репликации.

Однако, когда mysqlbinlog анализирует a SET @@sql_mode = mode оператор, полное mode значение, включая NO_DIR_IN_CREATE, передается к серверу получения. Поэтому репликация такого оператора, возможно, не безопасна когда STATEMENT режим используется.

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

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

max_heap_table_size системная переменная не тиражируется. Увеличение значения этой переменной на ведущем устройстве, не делая так на ведомом устройстве может привести в конечном счете к Таблице, полные ошибки на ведомом устройстве, пытаясь выполниться INSERT операторы на a MEMORY таблица на ведущем устройстве, которому таким образом разрешают вырасти чем ее дубликат на ведомом устройстве. Для получения дополнительной информации см. Раздел 16.4.1.21, "Репликация и MEMORY Таблицы".

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

SET max_join_size=1000;INSERT INTO mytable VALUES(@@max_join_size);

Это не применяется к общей последовательности:

SET time_zone=...;INSERT INTO mytable VALUES(CONVERT_TZ(..., ..., @@time_zone));

Репликация переменных сеанса не является проблемой, когда построчная репликация используется, когда, переменные сеанса всегда тиражируются безопасно. См. Раздел 16.1.2, "Форматы Репликации".

В MySQL 5.6 следующие переменные сеанса пишутся двоичному журналу и соблюдаются ведомым устройством репликации, анализируя двоичный журнал, независимо от формата журналирования:

Важный

Даже при том, что переменные сеанса, касающиеся наборов символов и сопоставлений, пишутся двоичному журналу, репликация между различными наборами символов не поддерживается.

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

Отметить

В предыдущих версиях MySQL, когда чувствительная к регистру файловая система использовалась, устанавливая эту переменную в 1 на ведомом устройстве и в различное значение на ведущем устройстве, мог привести к отказу репликации. Эта проблема устраняется в MySQL 5.6.1. (Ошибка #37656)