You can set REQUIRE_ROW_FORMAT  for a replication channel whether or not you set a PRIVILEGE_CHECKS_USER  account. The restrictions implemented when you set this option increase the security of the replication channel even without privilege checks. You can also specify the -- require-row-format  option when you use mysqlbinlog , to enforce row-based replication events in mysqlbinlog  output. 

Security Context.  By default, when a replication applier thread is started with a user account specified as the PRIVILEGE_CHECKS_USER , the security context is created using default roles, or with all roles if activate_all_roles_on_login  is set to ON . 

You can use roles to supply a general privilege set to accounts that are used as PRIVILEGE_CHECKS_USER  accounts, as in the following example. Here, instead of granting the INSERT  privilege for the db1.cust  table directly to a user account as in the earlier example, this privilege is granted to the role priv_repl_role  along with the REPLICATION_APPLIER  privilege. The role is then used to grant the privilege set to two user accounts, both of which can now be used as PRIVILEGE_CHECKS_USER  accounts: 

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; 

Be aware that when the replication applier thread creates the security context, it checks the privileges for the PRIVILEGE_CHECKS_USER  account, but does not carry out password validation, and does not carry out checks relating to account management, such as checking whether the account is locked. The security context that is created remains unchanged for the lifetime of the replication applier thread. 

Limitation.  In MySQL 8.0.18 only, if the replica mysqld  is restarted immediately after issuing a RESET REPLICA | SLAVE  statement (due to an unexpected server exit or deliberate restart), the PRIVILEGE_CHECKS_USER  account setting, which is held in the mysql.slave_relay_log_info table, is lost and must be respecified. When you use privilege checks in that release, always verify that they are in place after a restart, and respecify them if required. From MySQL 8.0.19, the PRIVILEGE_CHECKS_USER  account setting is preserved in this situation, so it is retrieved from the table and reapplied to the channel. 

## 17.3.3.1 Privileges For The Replication PRIVILEGE_CHECKS_USER Account 

The user account that is specified using the CHANGE REPLICATION SOURCE TO  | CHANGE MASTER TO  statement as the PRIVILEGE_CHECKS_USER  account for a replication channel must have the REPLICATION_APPLIER  privilege, otherwise the replication applier thread does not start. As explained in Section 17.3.3, “Replication Privilege Checks” , the account requires further privileges that are sufficient to apply all the expected transactions expected on the replication channel. These privileges are checked only when relevant transactions are executed. 

The use of row-based binary logging ( binlog_format=ROW ) is strongly recommended for replication channels that are secured using a PRIVILEGE_CHECKS_USER  account. With statement-based binary 

