16.1.2.3. Определение Безопасных и Опасных Операторов в Двоичном Журналировании

Говоря о "безопасности" оператора в MySQL Replication, мы обращаемся к тому, могут ли оператор и его эффекты быть тиражированы, правильно используя основанный на операторе формат. Если это верно для оператора, мы обращаемся к оператору как безопасный; иначе, мы обращаемся к этому как опасный.

Вообще, оператор безопасен, если это детерминированный, и опасный, если это не. Однако, определенные недетерминированные функции не считают опасными (см. Недетерминированные функции, которые не рассматривают опасными, позже в этом разделе). Кроме того, операторы используя следствия математических функций с плавающей точкой — которые аппаратно-зависимы — всегда считают безопасными (см. Раздел 16.4.1.12, "Репликация и Значения С плавающей точкой").

Обработка безопасных и опасных операторов. Оператор обрабатывается по-другому в зависимости от того, считают ли оператор безопасным, и относительно двоичного формата журналирования (то есть, текущая стоимость binlog_format).

Никакое различие не делается в обработке безопасных и опасных операторов, когда двоичный режим журналирования ROW.
Если двоичный формат журналирования MIXED, операторы, отмеченные как опасный, регистрируются, используя основанный на строке формат; операторы, расцененные как безопасный, регистрируются, используя основанный на операторе формат.
Если двоичный формат журналирования STATEMENT, операторы, отмеченные как являющийся опасным, генерируют предупреждение с этой целью. (Безопасные операторы обычно регистрируются.)

Каждый оператор, отмеченный как опасный, генерирует предупреждение. Прежде, в случаях, где очень много таких операторов выполнялись на ведущем устройстве, это могло привести к очень большим файлам журнала ошибок, иногда даже заполняя весь диск неожиданно. Принять меры против этого, MySQL 5.6.7, представленный механизм подавления предупреждения, который ведет себя следующим образом: Всякий раз, когда новые 50 ER_BINLOG_UNSAFE_STATEMENT предупреждения были сгенерированы больше чем 50 раз в любой 50-секундный период, предупреждая, что подавление включается. Когда активировано, это заставляет такие предупреждения не быть записанными журналу ошибок; вместо этого, для каждого 50 предупреждений этого типа, примечания The last warning was repeated N times in last S seconds пишется журналу ошибок. Это продолжается пока 50, новые, такие предупреждения были выпущены через 50 секунд или меньше; как только уровень уменьшился ниже этого порога, предупреждения еще раз обычно регистрируются. Предупреждение подавления не имеет никакого эффекта на то, как безопасность операторов для основанного на операторе журналирования определяется, ни на том, как предупреждения отправляются клиенту (клиенты MySQL все еще получают предупреждение того для каждого такого оператора).

Для получения дополнительной информации см. Раздел 16.1.2, "Форматы Репликации".

Операторы, которые рассматривают опасным. Операторы, имеющие следующие характеристики, считают опасными:

Операторы, содержащие системные функции, которые могут возвратить различное значение на ведомом устройстве. Эти функции включают FOUND_ROWS(), GET_LOCK(), IS_FREE_LOCK(), IS_USED_LOCK(), LOAD_FILE(), MASTER_POS_WAIT(), PASSWORD(), RAND(), RELEASE_LOCK(), ROW_COUNT(), SESSION_USER(), SLEEP(), SYSDATE(), SYSTEM_USER(), USER(), UUID(), и UUID_SHORT().

Недетерминированные функции, которые не рассматривают опасным. Хотя эти функции не детерминированы, они обрабатываются как безопасные в целях зарегистрировать и репликация: CONNECTION_ID(), CURDATE(), CURRENT_DATE(), CURRENT_TIME(), CURRENT_TIMESTAMP(), CURTIME(),, LAST_INSERT_ID(), LOCALTIME(), LOCALTIMESTAMP(), NOW(), UNIX_TIMESTAMP(), UTC_DATE(), UTC_TIME(), и UTC_TIMESTAMP().

Для получения дополнительной информации см. Раздел 16.4.1.15, "Репликация и Системные функции".
Ссылки на системные переменные. Большинство системных переменных не тиражируется, правильно используя основанный на операторе формат. Для исключений см. Раздел 5.2.4.3, "Смешанный Двоичный Формат Журналирования".

См. Раздел 16.4.1.33, "Репликация и Переменные".
UDFs. Так как мы не имеем никакого контроля над тем, что делает UDF, мы должны предположить, что он выполняет опасные операторы.
Обновляет таблицу, имеющую AUTO_INCREMENT столбец. Это опасно, потому что порядок, в котором обновляются строки, может разойтись в ведущем устройстве и ведомом устройстве.

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

Для получения дополнительной информации см. Раздел 16.4.1.1, "Репликация и AUTO_INCREMENT".
INSERT DELAYED оператор. Этот оператор считают опасным, потому что вставка строк может чередоваться с одновременно выполняющимися операторами.
INSERT ... ON DUPLICATE KEY UPDATE операторы на таблицах с многократными первичными или уникальными ключами. Когда выполняющийся против таблицы, которая содержит больше чем один первичный или уникальный ключ, этот оператор считают опасным, будучи чувствительным к порядку, в который механизм хранения проверяет ключи, который не детерминирован, и от которого зависит выбор строк, обновленных MySQL Server.

INSERT ... ON DUPLICATE KEY UPDATE оператор против таблицы, имеющей больше чем один уникальный или первичный ключ, отмечается как опасный для основанной на операторе репликации, начинающейся с MySQL 5.6.6. (Ошибка #11765650, Ошибка #58637)
Использование обновлений LIMIT. Порядок, в котором получаются строки, не определяется.

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

Для получения дополнительной информации см. Раздел 16.4.1.30, "Репликация и Транзакции".
Доступы или ссылки, саморегистрирующие таблицы. Все чтения и записи к саможурналированию таблиц считают опасными. В пределах транзакции любой оператор после чтения или записи к саможурналированию таблиц также считают опасным.
LOAD DATA INFILE операторы. Начинание с MySQL 5.6, LOAD DATA INFILE считается опасным, это вызывает предупреждение в основанном на операторе режиме, и переключатель к основанному на строке формату при использовании журналирования смешанного формата. См. Раздел 16.4.1.17, "Репликация и LOAD DATA INFILE".

Для дополнительной информации см. Раздел 16.4.1, "Функции репликации и Проблемы".