Двоичное протоколирование хранимых процедур

Двоичное протоколирование может быть на основе строк, на основе операторов или представлять собой смесь обоих. Смотрите Форматы двоичного протоколирования для получения более подробной информации о форматах. Если протоколирование выполняется на основе операторов, оператор может иметь разные эффекты на главном и на ведомом серверах.

Хранимые процедуры особенно подвержены этому по двум основным причинам:

• хранимые процедуры могут быть недетерминированными, то есть невоспроизводимыми, и поэтому каждый раз при выполнении они могут давать разные результаты.
• поток выполнения хранимой процедуры на ведомом сервере имеет полные привилегии, в то время как при выполнении процедуры на главном сервере это может быть не так.

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

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

Как MariaDB обрабатывает двоичное протоколирование хранимых процедур на основе операторов

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

• Включен двоичный журнал, и системная переменная binlog_format установлена в STATEMENT. См. Форматы двоичного протоколирования для получения дополнительной информации.
• Переменная log_bin_trust_function_creators установлена в OFF, что является значением по умолчанию.

Если вышеуказанные критерии выполнены, применяются следующие ограничения:

• При создании хранимой функции, она должна быть объявлена как DETERMINISTIC, NO SQL или READS SQL DATA, иначе произойдет ошибка. MariaDB не может проверить, является ли функция детерминированной, и полагается на правильное использование определения.
• Для создания или изменения хранимой функции пользователю необходимы привилегии SUPER, а также обычные привилегии. См. Привилегии хранимых процедур для получения подробной информации.
• Триггеры работают аналогичным образом, за исключением того, что для целей протоколирования они всегда предполагаются детерминированными, даже если это очевидно не так, например, при использовании функции UUID.
• Триггеры также могут обновлять данные. Ведомый сервер использует атрибут DEFINER, чтобы определить, какой пользователь считается создателем триггера.
• Обратите внимание, что вышеуказанные ограничения не применяются к хранимым процедурам или событиям.

Примеры

Детерминированная функция:

DELIMITER //
 
CREATE FUNCTION trust_me(x INT)
RETURNS INT
DETERMINISTIC
READS SQL DATA
BEGIN
   RETURN (x);
END //
 
DELIMITER ;

Недетерминированная функция, так как она использует функцию UUID_SHORT:

DELIMITER //

CREATE FUNCTION dont_trust_me()
RETURNS INT
BEGIN
   RETURN UUID_SHORT();
END //

DELIMITER ;