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

Использование построчного двоичного протоколирования (binlog_format=ROW) настоятельно рекомендуется для каналов репликации, защищённых с помощью учётной записи PRIVILEGE_CHECKS_USER. При использовании операторно-ориентированного двоичного протоколирования для учётной записи 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 для переопределения настройки шифрования по умолчанию. Настоятельно рекомендуется не предоставлять это разрешение. Вместо этого убедитесь, что значение шифрования по умолчанию на реплике соответствует статусу шифрования файловых систем, которые она реплицирует, и что члены группы репликации имеют одинаковое значение шифрования по умолчанию, чтобы это разрешение не потребовалось.

Для выполнения конкретных транзакций репликации из журнала relay или транзакций из вывода 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.19, «Репликация и 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) для фильтрации этой базы данных на реплике.