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

Что будет делать 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.

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

Разработка регистрации сохраненной подпрограммы в MySQL 5.0 может быть получена в итоге следующим образом:

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

MySQL 5.0.6: инструкции, которые создают сохраненные подпрограммы, и инструкции CALL регистрируются. Сохраненные функциональные вызовы регистрируются, когда они происходят в инструкциях, которые модифицируют данные (потому что те инструкции регистрируются). Однако, функциональные вызовы не регистрируются, когда они происходят в инструкциях типа SELECT, которые не изменяют данные, даже если изменение данных происходит непосредственно внутри функции, это может вызвать проблемы. При некоторых обстоятельствах, функции и процедуры могут иметь различные эффекты если выполнено в разное время или на различных серверах (главном или подчиненном), и таким образом они могут быть опасны для восстановления данных или дублирования. Чтобы обрабатывать это, приняты меры, чтобы позволить идентификацию безопасных подпрограмм и предотвратить создание опасных подпрограмм (за исключением создаваемых пользователями с достаточными привилегиями).