user account’s privileges to verify that you have authorized the operation for that channel. The account can also be safely used by an administrator to apply or reapply transactions from mysqlbinlog  output, for example to recover from a replication error on the channel. 

The use of a PRIVILEGE_CHECKS_USER  account helps secure a replication channel against the unauthorized or accidental use of privileged or unwanted operations. The PRIVILEGE_CHECKS_USER account provides an additional layer of security in situations such as these: 

•You are replicating between a server instance on your organization’s network, and a server instance on another network, such as an instance supplied by a cloud service provider. 

•You want to have multiple on-premise or off-site deployments administered as separate units, without giving one administrator account privileges on all the deployments. 

•You want to have an administrator account that enables an administrator to perform only operations that are directly relevant to the replication channel and the databases it replicates, rather than having wide privileges on the server instance. 

You can increase the security of a replication channel where privilege checks are applied by adding one or both of these options to the CHANGE REPLICATION SOURCE TO  | CHANGE MASTER TO  statement when you specify the PRIVILEGE_CHECKS_USER  account for the channel: 

•The REQUIRE_ROW_FORMAT  option (available from MySQL 8.0.19) makes the replication channel accept only row-based replication events. When REQUIRE_ROW_FORMAT  is set, you must use row-based binary logging ( binlog_format=ROW ) on the source server. In MySQL 8.0.18, REQUIRE_ROW_FORMAT  is not available, but the use of row-based binary logging for secured replication channels is still strongly recommended. With statement-based binary logging, some administrator-level privileges might be required for the PRIVILEGE_CHECKS_USER  account to execute transactions successfully. 

•The REQUIRE_TABLE_PRIMARY_KEY_CHECK  option (available from MySQL 8.0.20) makes the replication channel use its own policy for primary key checks. Setting ON  means that primary keys are always required, and setting OFF  means that primary keys are never required. The default setting, STREAM , sets the session value of the sql_require_primary_key  system variable using the value that is replicated from the source for each transaction. When PRIVILEGE_CHECKS_USER  is set, setting REQUIRE_TABLE_PRIMARY_KEY_CHECK  to either ON  or OFF  means that the user account does not need session administration level privileges to set restricted session variables, which are required to change the value of sql_require_primary_key . It also normalizes the behavior across replication channels for different sources. 

You grant the REPLICATION_APPLIER  privilege to enable a user account to appear as the PRIVILEGE_CHECKS_USER  for a replication applier thread, and to execute the internal-use BINLOG statements used by mysqlbinlog. The user name and host name for the PRIVILEGE_CHECKS_USER account must follow the syntax described in Section 6.2.4, “Specifying Account Names” , and the user must not be an anonymous user (with a blank user name) or the CURRENT_USER . To create a new account, use CREATE USER . To grant this account the REPLICATION_APPLIER  privilege, use the GRANT  statement. For example, to create a user account priv_repl , which can be used manually by an administrator from any host in the example.com  domain, and requires an encrypted connection, issue the following statements: 

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; 

The SET sql_log_bin  statements are used so that the account management statements are not added to the binary log and sent to the replication channels (see Section 13.4.1.3, “SET sql_log_bin Statement” ). 

