MySQL: руководство профессионала

Будут ли сохраненные процедуры и функции, созданные на главном сервере, скопированы на подчиненный?

Да, создание сохраненных процедур и функций, выполненное через нормальные инструкции DDL, скопируется на подчиненный, так что объекты будут существовать на обеих серверах. Инструкции ALTER и DROP для сохраненных процедур и функций также скопируются.

Как реплицируются действия, которые происходят внутри сохраненных процедур и скопированных функций?

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

Есть ли специальные требования защиты для использования сохраненных процедур и функций вместе с репликацией?

Да. Поскольку подчиненный сервер имеет полномочия, выполнить любое операторное чтение из двоичного файла регистрации главного сервера, специальные ограничения защиты существуют для использования сохраненных функций с репликацией. Если репликация или двоичная регистрация вообще (с целью восстановления в контрольной точке активна, то MySQL DBA имеет два параметров защиты для них:

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

В качестве альтернативы, DBA может устанавливать переменную системы log_bin_trust_function_creators в 1, что позволяет любому со стандартной привилегией CREATE ROUTINE создавать сохраненные функции.

Обратите внимание: до MySQL 5.0.16 эти ограничения также относятся к сохраненным процедурам, и переменная системы именована log_bin_trust_routine_creators.

Какие ограничения существуют для копирования сохраненной процедуры и функциональных действий?

Не детерминированные (произвольные) или основанные на времени действия, внедренные в сохраненных процедурах, не могут копироваться правильно. Для них очень характерны беспорядочно произведенные не предсказуемые результаты, которые не могут быть точно воспроизведены, а, следовательно, произвольные действия, скопированные на подчиненный сервер, не будут отражать, что именно выполнили на главном сервере. Обратите внимание, что объявление сохраненных функций как DETERMINISTIC или установка переменной системы log_bin_trust_function_creators в 0 не будет позволять вызывать произвольно оцененные операции.

Кроме того, основанные на времени действия не могут быть воспроизведены на подчиненном сервере, потому что синхронизация таких действий в сохраненной процедуре не восстанавливаема через двоичный файл регистрации, используемый для репликации. Он записывает только события DML и не разлагает их на множители в ограничениях синхронизации.

В заключение, нетранзакционные таблицы, для которых происходят ошибки в течение больших действий DML (типа объемных вставок), могут испытывать проблемы дублирования, в которых главный сервер может частично модифицироваться из действия DML, но никакие модификации не выполнены на подчиненном из-за ошибок, которые произошли. Обойти проблему можно с ключевым словом IGNORE так, чтобы модификации на главном сервере, которые вызывают ошибки, игнорировались, а модификации, которые не вызывают ошибок, скопируются на подчиненный.

Предшествующие ограничения воздействуют на способность MySQL делать восстановление до контрольной точки?

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

Что будет делать MySQL, чтобы исправить вышеупомянутые ограничения?

Будущий выпуск MySQL, как ожидается, даст выбор в том, как репликация должна быть обработана:

Операторно-основанная репликация (текущая реализация).

Дублирование уровня строки (которое решит все ограничения, описанные ранее).

Триггеры работают с репликацией?

Триггеры и репликация в MySQL 5.0 работают также как в большинстве других СУБД: действия, выполненные через триггеры на главном сервере, не скопируются на подчиненный. Вместо этого, триггеры, которые существуют на таблицах, которые постоянно находятся на главном сервере, должны быть созданы на соответствующих таблицах на любых подчиненных серверах так, чтобы триггеры активизировались там соответственно главному.

Как действия, выполненные через триггер на главном сервере, скопированы на подчиненный?

Сначала, триггеры, которые существуют на главном сервере, должны быть вновь созданы на подчиненном сервере. Если это выполнено, поток дублирования работает как любая другая стандартная инструкция DML, которая участвует в дублировании. Например, рассмотрите таблицу EMP, которая имеет триггер AFTER insert, существующий на главном сервере. Та же самая таблица и триггер существуют также и на подчиненном сервере. Поток дублирования был бы:

Инструкция INSERT сделана в EMP.

Триггер AFTER сработал на EMP.

Инструкция INSERT записана в двоичный файл регистрации.

Подчиненный сервер подбирает инструкцию INSERT к EMP и выполняет ее.

Триггер AFTER в EMP, который существует на подчиненном сервере, активизируется.

5.5. Двоичная регистрация сохраненных подпрограмм и триггеров

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

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

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

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

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