19.3.3.3 Recovering From Failed Replication Privilege Checks — MySQL 8.4

19.3.3.3 Восстановление после сбоя проверки привилегий репликации

Если проверка привилегий для учетной записи PRIVILEGE_CHECKS_USER завершится неудачно, транзакция не будет выполнена, и репликация остановится для канала. Сведения об ошибке и последней применённой транзакции записываются в таблицу Performance Schema replication_applier_status_by_worker. Восстановитесь от ошибки, выполнив следующие действия:

Определите событие репликации, вызвавшее ошибку, и проверьте, ожидалось ли это событие и поступало ли оно из надёжного источника. Вы можете использовать mysqlbinlog для получения и отображения событий, записанных около времени возникновения ошибки. Инструкции по выполнению этого действия см. в Разделе 9.5, «Восстановление по состоянию на определённый момент времени (инкрементное)».
Если событие репликации не ожидалось или не поступало из известного и надёжного источника, выясните причину. Если вы можете определить причину события и нет соображений безопасности, перейдите к устранению ошибки, как описано ниже.
Если учетная запись PRIVILEGE_CHECKS_USER должна была иметь разрешение на выполнение транзакции, но была неправильно настроена, предоставьте недостающие привилегии учетной записи, используйте инструкцию FLUSH PRIVILEGES или выполните команду mysqladmin flush-privileges или mysqladmin reload для перезагрузки таблиц предоставления разрешений, а затем перезапустите репликацию для канала.
Если транзакция должна быть выполнена, и вы подтвердили её надёжность, но учетная запись PRIVILEGE_CHECKS_USER обычно не должна иметь этих привилегий, вы можете временно предоставить требуемые привилегии учетной записи PRIVILEGE_CHECKS_USER. После применения события репликации удалите привилегию из учетной записи и выполните необходимые действия, чтобы предотвратить повторное возникновение события, если это возможно.
Если транзакция — это административное действие, которое должно было быть выполнено только на источнике, а не на реплике, или должно было быть выполнено только на одном члене группы репликации, пропустите транзакцию на сервере или серверах, где остановилась репликация, а затем выполните START REPLICA для перезапуска репликации на канале. Чтобы избежать такой ситуации в будущем, можно выполнить такие административные инструкции с SET sql_log_bin = 0 перед ними и SET sql_log_bin = 1 после них, чтобы они не регистрировались на источнике.
Если транзакция — это инструкция DDL или DML, которая не должна была быть выполнена ни на источнике, ни на реплике, пропустите транзакцию на сервере или серверах, где остановилась репликация, откатайте транзакцию вручную на сервере, где она была первоначально выполнена, а затем выполните START REPLICA для перезапуска репликации.

Для пропуска транзакции, если используются GTID, выполните пустую транзакцию с GTID транзакции с ошибкой, например:

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';

Если GTID не используются, выполните инструкцию SET GLOBAL sql_replica_skip_counter для пропуска события. Инструкции по использованию этого альтернативного метода и более подробные сведения о пропускании транзакций см. в Разделе 19.1.7.3, «Пропуск транзакций».