Если оператор генерирует одинаковую ошибку (одинаковый код ошибки) как на источнике, так и на реплике, ошибка регистрируется, но репликация продолжается.

Если оператор генерирует разные ошибки на источнике и на реплике, поток SQL репликации завершается, и реплика записывает сообщение в свой журнал ошибок и ожидает, пока администратор базы данных решит, что делать с ошибкой. Это включает случай, когда оператор генерирует ошибку на источнике или реплике, но не на обоих. Для решения проблемы подключитесь к реплике вручную и определите причину проблемы. SHOW REPLICA STATUS полезен для этого. Затем исправьте проблему и выполните START REPLICA. Например, вам может потребоваться создать несуществующую таблицу, прежде чем вы сможете снова запустить реплику.

Если поведение проверки кода ошибки нежелательно, некоторые или все ошибки могут быть замаскированы (проигнорированы) с помощью опции --replica-skip-errors.

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

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

Правила фильтрации репликации применяются первыми, до проверки привилегий или формата строк, что позволяет отфильтровать любые транзакции, не прошедшие проверку; никакие проверки не выполняются, и для транзакций, которые были отфильтрованы, не генерируются ошибки. Это означает, что реплика может принять только ту часть базы данных, к которой данному пользователю предоставлен доступ (поскольку любые обновления этой части базы данных используют формат репликации на основе строк). Это может быть полезно при выполнении обновления или при миграции в систему или приложение, которые используют административные таблицы, к которым у пользователя входящей репликации нет доступа. См. также Раздел 19.2.5, «Как серверы оценивают правила фильтрации репликации».