По умолчанию MySQL репликация (включая групповую репликацию) не выполняет проверку привилегий при применении транзакций, уже принятых другим сервером, на реплике или члене группы. Вы можете создать учетную запись пользователя с соответствующими привилегиями для применения транзакций, которые обычно реплицируются по каналу, и указать её как учетную запись PRIVILEGE_CHECKS_USER для приложения репликации, используя инструкцию 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 для канала отображаются в таблице Performance Schema replication_applier_configuration, где они корректно экранированы, чтобы их можно было скопировать напрямую в инструкции SQL для выполнения отдельных транзакций.

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

При установке параметра 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, но не выполняет проверку пароля и не выполняет проверки, связанные с управлением учётными записями, такие как проверка, заблокирована ли учётная запись. Контекст безопасности, который создаётся, остаётся неизменным на протяжении всего жизненного цикла потока приложения-приемника репликации.