Учетная запись пользователя, указанная с помощью оператора CHANGE REPLICATION SOURCE TO в качестве учетной записи PRIVILEGE_CHECKS_USER для канала репликации, должна иметь разрешение REPLICATION_APPLIER, иначе поток репликации-применителя не запустится. Как объясняется в разделе 19.3.3 «Проверка разрешений репликации», учетная запись требует дополнительных разрешений, достаточных для применения всех ожидаемых транзакций на канале репликации. Эти разрешения проверяются только при выполнении соответствующих транзакций.

Для каналов репликации, защищенных с помощью учетной записи PRIVILEGE_CHECKS_USER, настоятельно рекомендуется использовать двоичный журнал на основе строк (binlog_format=ROW). При использовании двоичного журнала на основе операторов для успешного выполнения транзакций учетной записи PRIVILEGE_CHECKS_USER могут потребоваться некоторые разрешения административного уровня. Параметр REQUIRE_ROW_FORMAT может быть применён к защищённым каналам, что ограничивает выполнение событий, требующих этих разрешений.

Разрешение REPLICATION_APPLIER явно или неявно позволяет учетной записи PRIVILEGE_CHECKS_USER выполнять следующие операции, необходимые потоку репликации:

Если опция REQUIRE_TABLE_PRIMARY_KEY_CHECK оператора CHANGE REPLICATION SOURCE TO установлена в значение по умолчанию STREAM, учетной записи PRIVILEGE_CHECKS_USER необходимы разрешения, достаточные для установки ограниченных переменных сеанса, чтобы она могла изменить значение системной переменной sql_require_primary_key на время сеанса в соответствии с настройкой, скопированной с источника. Разрешение SESSION_VARIABLES_ADMIN предоставляет учетной записи эту возможность. Это разрешение также позволяет учетной записи применять вывод mysqlbinlog, созданный с помощью опции --disable-log-bin. Если вы установите REQUIRE_TABLE_PRIMARY_KEY_CHECK в ON или OFF, реплика всегда использует это значение для системной переменной sql_require_primary_key в операциях репликации и, следовательно, не нуждается в этих разрешениях администратора сеанса.

Если используется шифрование таблиц, системная переменная table_encryption_privilege_check установлена в ON, а настройка шифрования для табличного пространства, участвующего в любом событии, отличается от стандартной настройки шифрования сервера приложения (указанной системной переменной default_table_encryption), учетная запись PRIVILEGE_CHECKS_USER нуждается в разрешении TABLE_ENCRYPTION_ADMIN для переопределения стандартной настройки шифрования. Настоятельно рекомендуется не предоставлять это разрешение. Вместо этого убедитесь, что стандартная настройка шифрования на реплике соответствует статусу шифрования табличных пространств, которые она реплицирует, и что члены группы репликации имеют одинаковую стандартную настройку шифрования, чтобы разрешение не требовалось.

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

Если используется двоичный журнал на основе операторов (что не рекомендуется с учетной записью PRIVILEGE_CHECKS_USER), для оператора управления транзакциями, такого как BEGIN или COMMIT, или DML, залогированных в формате операторов (которые регистрируются как Query_log_event), учетной записи PRIVILEGE_CHECKS_USER необходимы разрешения для выполнения оператора, содержащегося в событии.

Если необходимо выполнить операции LOAD DATA на канале репликации, используйте двоичный журнал на основе строк (binlog_format=ROW). В этом формате записи разрешение FILE не требуется для выполнения события, поэтому не предоставляйте это разрешение учетной записи PRIVILEGE_CHECKS_USER. Использование двоичного журнала на основе строк настоятельно рекомендуется для каналов репликации, защищенных с помощью учетной записи PRIVILEGE_CHECKS_USER. Если REQUIRE_ROW_FORMAT установлено для канала, требуется двоичный журнал на основе строк. Format_description_log_event, удаляющая все временные файлы, созданные событиями LOAD DATA, обрабатывается без проверки разрешений. Дополнительную информацию см. в разделе 19.5.1.20 «Репликация и LOAD DATA».

Если системная переменная init_replica установлена для указания одного или нескольких операторов SQL, которые будут выполняться при запуске потока репликации SQL, учетная запись PRIVILEGE_CHECKS_USER должна иметь необходимые разрешения для выполнения этих операторов.

Рекомендуется никогда не предоставлять учетной записи PRIVILEGE_CHECKS_USER какие-либо разрешения ACL, включая CREATE USER, CREATE ROLE, DROP ROLE и GRANT OPTION, и не разрешать учетной записи обновлять таблицу mysql.user. С этими разрешениями учетная запись может использоваться для создания или изменения учетных записей пользователей на сервере. Чтобы избежать репликации на защищенный канал для выполнения операторов ACL, выпущенных на сервере-источнике (где они завершатся неудачно в отсутствие этих разрешений), можно выполнить SET sql_log_bin = 0 перед всеми операторами ACL и SET sql_log_bin = 1 после них, чтобы исключить эти операторы из двоичного журнала источника. В качестве альтернативы можно установить определённую текущую базу данных перед выполнением всех операторов ACL и использовать фильтр репликации (--binlog-ignore-db) для фильтрации этой базы данных на реплике.