Сервер записывает операторы 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, требование о том, что функции должны быть детерминированными или не должны изменять данные, отменяется.

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

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

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