Сервер записывает CREATE EVENT, CREATE PROCEDURE, CREATE FUNCTION, ALTER EVENT, ALTER PROCEDURE, ALTER FUNCTION, DROP EVENT, DROP PROCEDURE и DROP FUNCTION операторы в двоичный журнал.

Вызов хранимой функции регистрируется как оператор SELECT, если функция изменяет данные и происходит внутри оператора, который в противном случае не регистрировался бы. Это предотвращает нерепликацию изменений данных, которые возникают в результате использования хранимых функций в операторах, не предназначенных для ведения журнала. Например, операторы SELECT не записываются в двоичный журнал, но оператор SELECT может вызвать хранимую функцию, которая вносит изменения. Для обработки этого оператор SELECT func_name() записывается в двоичный журнал, когда указанная функция вносит изменения. Предположим, что на сервере-источнике выполняются следующие операторы:

CREATE FUNCTION f1(a INT) RETURNS INT
BEGIN
  IF (a < 3) THEN
    INSERT INTO t2 VALUES (a);
  END IF;
  RETURN 0;
END;

CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2),(3);

SELECT f1(a) FROM t1;

При выполнении оператора SELECT, функция f1() вызывается три раза. Два из этих вызовов вставляют строку, и MySQL записывает оператор SELECT для каждого из них. То есть MySQL записывает следующие операторы в двоичный журнал:

SELECT f1(1);
SELECT f1(2);

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

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

Последствием является то, что хотя пользователю необходимо иметь привилегию CREATE ROUTINE для создания функции, пользователь может написать функцию, содержащую опасный оператор, который выполняется только на реплике, где он обрабатывается потоком, имеющим полные привилегии. Например, если значения идентификаторов сервера источника и реплики соответственно равны 1 и 2, пользователь на сервере-источнике может создать и вызвать небезопасную функцию unsafe_func() следующим образом:

mysql> delimiter //
mysql> CREATE FUNCTION unsafe_func () RETURNS INT
    -> BEGIN
    ->   IF @@server_id=2 THEN dangerous_statement; END IF;
    ->   RETURN 1;
    -> END;
    -> //
mysql> delimiter ;
mysql> INSERT INTO t VALUES(unsafe_func());

Операторы CREATE FUNCTION и INSERT записываются в двоичный журнал, поэтому реплика выполняет их. Поскольку поток применения реплики имеет полные привилегии, он выполняет опасный оператор. Таким образом, вызов функции имеет разные эффекты на сервере-источнике и реплике и не является безопасным для репликации.

Для защиты от этой опасности для серверов, у которых включено ведение двоичного журнала, создателям хранимых функций необходимо иметь привилегию SUPER в дополнение к обычной привилегии CREATE ROUTINE, которая требуется. Аналогично, для использования ALTER FUNCTION вам необходимо иметь привилегию SUPER в дополнение к привилегии ALTER ROUTINE. Без привилегии SUPER возникает ошибка:

ERROR 1419 (HY000): You do not have the SUPER privilege and
binary logging is enabled (you *might* want to use the less safe
log_bin_trust_function_creators variable)

Если вы не хотите требовать, чтобы создатели функций имели привилегию SUPER (например, если все пользователи с привилегией CREATE ROUTINE в вашей системе являются опытными разработчиками приложений), установите системную переменную log_bin_trust_function_creators в значение 1. Вы также можете установить эту переменную при запуске сервера. Если ведение двоичного журнала не включено, log_bin_trust_function_creators не применяется. Привилегия SUPER не требуется для создания функции, если, как описано ранее, значение DEFINER в определении функции требует этого.

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

Если функция, выполняющая обновления, является недетерминированной, она не повторяема. Это может иметь два нежелательных эффекта:

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

По умолчанию для принятия оператора CREATE FUNCTION необходимо явно указать хотя бы одну из характеристик DETERMINISTIC, NO SQL или READS SQL DATA. В противном случае возникает ошибка:

ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,
or READS SQL DATA in its declaration and binary logging is enabled
(you *might* want to use the less safe log_bin_trust_function_creators
variable)

Если вы установите log_bin_trust_function_creators в значение 1, требование, чтобы функции были детерминированными или не изменяли данные, отменяется.

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

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

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