По умолчанию, репликация MySQL (включая групповую репликацию) не выполняет проверку привилегий при применении транзакций, уже принятых другим сервером, на реплике или члене группы. Вы можете создать учётную запись пользователя с соответствующими привилегиями для применения транзакций, которые обычно реплицируются по каналу, и указать её как учётную запись приложения репликации, используя оператор CHANGE REPLICATION SOURCE TO. MySQL затем проверяет каждую транзакцию на предмет привилегий учётной записи пользователя, чтобы убедиться, что у вас есть разрешение на операцию для данного канала. Учётную запись также можно безопасно использовать администратору для применения или повторного применения транзакций из выходных данных mysqlbinlog, например, для восстановления после ошибки репликации в канале.

Использование учётной записи PRIVILEGE_CHECKS_USER помогает защитить канал репликации от несанкционированного или случайного использования привилегированных или нежелательных операций. Учётная запись PRIVILEGE_CHECKS_USER обеспечивает дополнительный уровень безопасности в таких ситуациях:

Вы можете повысить безопасность канала репликации, где применяются проверки привилегий, добавив один или оба из этих параметров к оператору CHANGE REPLICATION SOURCE TO, когда вы указываете учётную запись PRIVILEGE_CHECKS_USER для канала:

Вы предоставляете привилегию REPLICATION_APPLIER, чтобы позволить учётной записи пользователя выступать в роли PRIVILEGE_CHECKS_USER для потока приложения репликации и выполнять используемые внутренним механизмом операторы BINLOG, используемые mysqlbinlog. Имя пользователя и имя хоста для учётной записи PRIVILEGE_CHECKS_USER должны соответствовать синтаксису, описанному в Разделе 8.2.4, «Указание имён учётных записей», и пользователь не должен быть анонимным пользователем (с пустым именем пользователя) или CURRENT_USER. Для создания новой учётной записи используйте CREATE USER. Для предоставления этой учётной записи привилегии REPLICATION_APPLIER используйте оператор GRANT. Например, для создания учётной записи пользователя priv_repl, которую администратор может использовать вручную с любого хоста в домене example.com и которая требует зашифрованного соединения, выполните следующие операторы:

mysql> SET sql_log_bin = 0;
mysql> CREATE USER 'priv_repl'@'%.example.com' IDENTIFIED BY 'password' REQUIRE SSL;
mysql> GRANT REPLICATION_APPLIER ON *.* TO 'priv_repl'@'%.example.com';
mysql> SET sql_log_bin = 1;

Операторы SET sql_log_bin используются для того, чтобы операторы управления учётными записями не добавлялись в двоичный журнал и не отправлялись в каналы репликации (см. Раздел 15.4.1.3, «Оператор SET sql_log_bin»).

После настройки учётной записи используйте оператор GRANT для предоставления дополнительных привилегий, чтобы позволить учётной записи пользователя выполнять изменения в базе данных, которые, как ожидается, выполнит поток приложения, например, обновление определённых таблиц на сервере. Эти же привилегии позволяют администратору использовать учётную запись, если им необходимо выполнить вручную любые из этих транзакций в канале репликации. Если будет предпринята непредвиденная операция, для которой не было предоставлено соответствующих привилегий, операция будет запрещена, и поток приложения репликации остановится с ошибкой. Раздел 19.3.3.1, «Привилегии для учётной записи репликации PRIVILEGE_CHECKS_USER» объясняет, какие дополнительные привилегии необходимы для учётной записи. Например, чтобы предоставить учётной записи пользователя priv_repl привилегию INSERT для добавления строк в таблицу cust в db1, выполните следующий оператор:

mysql> GRANT INSERT ON db1.cust TO 'priv_repl'@'%.example.com';

Вы назначаете учётную запись PRIVILEGE_CHECKS_USER для канала репликации с помощью оператора CHANGE REPLICATION SOURCE TO. Если репликация выполняется, выполните STOP REPLICA перед оператором CHANGE REPLICATION SOURCE TO и START REPLICA после него. Использование двоичного журналика на основе строк настоятельно рекомендуется при установке PRIVILEGE_CHECKS_USER; вы можете использовать этот оператор для установки REQUIRE_ROW_FORMAT, чтобы обеспечить это.

При перезапуске канала репликации проверки динамических привилегий применяются с этого момента. Однако статические глобальные привилегии не активны в контексте приложения до тех пор, пока вы не перезагрузите таблицы разрешений, поскольку эти привилегии не изменяются для подключённого клиента. Чтобы активировать статические привилегии, выполните операцию flush-privileges. Это можно сделать, выполнив оператор FLUSH PRIVILEGES или выполнив команду mysqladmin flush-privileges или mysqladmin reload.

Например, чтобы запустить проверку привилегий в канале channel_1 на работающей реплике, выполните следующие операторы:

mysql> STOP REPLICA FOR CHANNEL 'channel_1';
mysql> CHANGE REPLICATION SOURCE TO
     >    PRIVILEGE_CHECKS_USER = 'priv_repl'@'%.example.com',
     >    REQUIRE_ROW_FORMAT = 1 FOR CHANNEL 'channel_1';
mysql> FLUSH PRIVILEGES;
mysql> START REPLICA FOR CHANNEL 'channel_1';

Если вы не указываете канал и других каналов не существует, оператор применяется к каналу по умолчанию. Имя пользователя и имя хоста для учётной записи PRIVILEGE_CHECKS_USER для канала показаны в таблице replication_applier_configuration схемы Performance Schema, где они должным образом экранированы, чтобы их можно было скопировать непосредственно в операторы SQL для выполнения отдельных транзакций.

Если вы используете подключаемый модуль Rewriter, вы должны предоставить учётной записи пользователя PRIVILEGE_CHECKS_USER привилегию SKIP_QUERY_REWRITE. Это предотвратит переписывание инструкций, выпущенных этим пользователем. См. Раздел 7.6.4, «Подключаемый модуль переписывания запросов Rewriter» для получения дополнительной информации.

При установке параметра REQUIRE_ROW_FORMAT для канала репликации, приложение-приемник репликации не создаёт и не удаляет временные таблицы, а также не устанавливает системную переменную сеанса pseudo_thread_id. Оно не выполняет инструкций LOAD DATA INFILE и не пытается выполнить файловые операции доступа или удаления временных файлов, связанных с загрузкой данных (записано как Format_description_log_event). Оно не выполняет события INTVAR, RAND и USER_VAR, используемые для воспроизведения состояния подключения клиента для репликации на основе заявлений. (Исключение составляют события USER_VAR, связанные с запросами DDL, которые выполняются). Оно не выполняет никаких инструкций, записанных в транзакциях DML. Если приложение-приемник репликации обнаруживает какой-либо из этих типов событий при попытке очереди или применения транзакции, то событие не применяется, и репликация останавливается с ошибкой.

Вы можете установить REQUIRE_ROW_FORMAT для канала репликации независимо от того, задали ли вы учётную запись PRIVILEGE_CHECKS_USER. Ограничения, введённые при установке этого параметра, повышают безопасность канала репликации даже без проверок привилегий. Вы также можете указать параметр --require-row-format при использовании mysqlbinlog, чтобы принудительно использовать события репликации на основе строк в выводе mysqlbinlog.

Контекст безопасности. По умолчанию, когда поток приложения-приемника репликации запускается с указанной учётной записью в качестве PRIVILEGE_CHECKS_USER, контекст безопасности создаётся с использованием ролей по умолчанию или со всеми ролями, если activate_all_roles_on_login установлено в ON.

Вы можете использовать роли для предоставления общего набора привилегий учётным записям, используемым в качестве PRIVILEGE_CHECKS_USER учётных записей, как в приведённом ниже примере. Вместо предоставления привилегии INSERT для таблицы db1.cust непосредственно учётной записи пользователя, как в предыдущем примере, эта привилегия предоставляется роли priv_repl_role вместе с привилегией REPLICATION_APPLIER. Затем эта роль используется для предоставления набора привилегий двум учётным записям пользователей, которые теперь могут использоваться в качестве PRIVILEGE_CHECKS_USER учётных записей:

mysql> SET sql_log_bin = 0;
mysql> CREATE USER 'priv_repa'@'%.example.com'
                  IDENTIFIED BY 'password'
                  REQUIRE SSL;
mysql> CREATE USER 'priv_repb'@'%.example.com'
                  IDENTIFIED BY 'password'
                  REQUIRE SSL;
mysql> CREATE ROLE 'priv_repl_role';
mysql> GRANT REPLICATION_APPLIER TO 'priv_repl_role';
mysql> GRANT INSERT ON db1.cust TO 'priv_repl_role';
mysql> GRANT 'priv_repl_role' TO
                  'priv_repa'@'%.example.com',
                  'priv_repb'@'%.example.com';
mysql> SET DEFAULT ROLE 'priv_repl_role' TO
                  'priv_repa'@'%.example.com',
                  'priv_repb'@'%.example.com';
mysql> SET sql_log_bin = 1;

Обратите внимание, что когда поток приложения-приемника репликации создаёт контекст безопасности, он проверяет привилегии для учётной записи PRIVILEGE_CHECKS_USER, но не выполняет проверку пароля и не выполняет проверки, связанные с управлением учётными записями, такие как проверка, заблокирована ли учётная запись. Контекст безопасности, который создаётся, остаётся неизменным на протяжении всего жизненного цикла потока приложения-приемника репликации.