Сервер записывает 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 записываются в двоичный журнал, поэтому реплика их выполняет. Поскольку реплицирующая SQL-нить имеет полные привилегии, она выполняет опасный оператор. Таким образом, вызов функции имеет разные эффекты на сервере источника и реплике и не является безопасным для репликации.

Для защиты от этой опасности для серверов с включённой двоичной записью создатели сохранённых функций должны иметь привилегию 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 в определении функции требует этого.

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

Для решения этих проблем 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, требование, чтобы функции были детерминированными или не изменяли данные, отпадает.

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

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

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