Spec-Zone .ru
спецификации, руководства, описания, API

18.7. Двоичное Журналирование Сохраненных Программ

Двоичный журнал содержит информацию о SQL-операторах, которые изменяют содержание базы данных. Эта информация хранится в форме "событий", которые описывают модификации. У двоичного журнала есть две важных цели:

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

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

Вообще, проблемы, описанные здесь, заканчиваются, когда двоичное журналирование происходит на уровне SQL-оператора. Если Вы используете основанное на строке двоичное журналирование, журнал содержит изменения, произведенные в отдельных строках в результате выполнения SQL-операторов. Когда подпрограммы или триггеры выполняются, изменения строки регистрируются, не операторы, которые производят изменения. Для хранимых процедур это означает что CALL оператор не регистрируется. Для сохраненных функций изменения строки, произведенные в пределах функции, регистрируются, не вызов функции. Для триггеров регистрируются изменения строки, произведенные триггером. На ведомой стороне только изменения строки замечаются, не сохраненный вызов программы. Для получения общей информации об основанном на строке журналировании, см. Раздел 16.1.2, "Форматы Репликации".

Если не отмечено иначе, комментарии здесь предполагают, что Вы включили двоичному журналированию, запуская сервер с --log-bin опция. (См. Раздел 5.2.4, "Двоичный Журнал".), Если двоичный журнал не включается, репликация не возможна, и при этом двоичный журнал не доступен для восстановления данных.

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

Триггеры подобны сохраненным функциям, таким образом, предыдущие комментарии относительно функций также применяются к триггерам со следующим исключением: CREATE TRIGGER не имеет дополнительного DETERMINISTIC характеристика, таким образом, триггеры, как предполагается, всегда детерминированы. Однако, это предположение могло бы в некоторых случаях быть недопустимым. Например, UUID() функция недетерминирована (и не тиражируется). Следует быть осторожными относительно использования таких функций в триггерах.

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

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