19.3.3.3 Recovering From Failed Replication Privilege Checks — MySQL 9.2

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 «Пропуск транзакций».