(which are logged as a  Query_log_event ), the  PRIVILEGE_CHECKS_USER  account needs privileges to execute the statement contained in the event. If  LOAD DATA  operations need to be carried out on the replication channel, use row-based binary logging ( binlog_format=ROW ). With this logging format, the  FILE  privilege is not needed to execute the event, so do not give the  PRIVILEGE_CHECKS_USER  account this privilege. The use of row-based binary logging is strongly recommended with replication channels that are secured using a  PRIVILEGE_CHECKS_USER account. If  REQUIRE_ROW_FORMAT  is set for the channel, row-based binary logging is required. The Format_description_log_event , which deletes any temporary files created by  LOAD DATA  events, is processed without privilege checks. For more information, see Section 17.5.1.19, “Replication and LOAD DATA” . If the  init_slave  system variable is set to specify one or more SQL statements to be executed when the replication SQL thread starts, the  PRIVILEGE_CHECKS_USER  account must have the privileges needed to execute these statements. It is recommended that you never give any ACL privileges to the  PRIVILEGE_CHECKS_USER  account, including  CREATE USER ,  CREATE ROLE ,  DROP ROLE , and  GRANT OPTION , and do not permit the account to update the  mysql.user  table. With these privileges, the account could be used to create or modify user accounts on the server. To avoid ACL statements issued on the source server being replicated to the secured channel for execution (where they fail in the absence of these privileges), you can issue SET sql_log_bin = 0  before all ACL statements and  SET sql_log_bin = 1  after them, to omit the statements from the source’s binary log. Alternatively, you can set a dedicated current database before executing all ACL statements, and use a replication filter ( --binlog-ignore-db ) to filter out this database on the replica. From MySQL 8.0.19, as well as securing asynchronous and semi-synchronous replication, you may choose to use a  PRIVILEGE_CHECKS_USER  account to secure the two replication applier threads used by Group Replication. The  group_replication_applier  thread on each group member is used for applying the group’s transactions, and the  group_replication_recovery  thread on each group member is used for state transfer from the binary log as part of distributed recovery when the member joins or rejoins the group. To secure one of these threads, stop Group Replication, then issue the  CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or  CHANGE MASTER TO  statement (before MySQL 8.0.23) with the  PRIVILEGE_CHECKS_USER  option, specifying  group_replication_applier  or group_replication_recovery  as the channel name. For example: For Group Replication channels, the  REQUIRE_ROW_FORMAT  setting is automatically enabled when the channel is created, and cannot be disabled, so you do not need to specify this. In MySQL 8.0.19, ensure that you do not issue the  CHANGE REPLICATION SOURCE TO  |  CHANGE MASTER TO  statement with the  PRIVILEGE_CHECKS_USER Important 3626 mysql>  STOP GROUP_REPLICATION; mysql>  CHANGE MASTER TO PRIVILEGE_CHECKS_USER = ’gr_repl’@’%.example.com’  FOR CHANNEL ’group_replication_recovery’; mysql>  START GROUP_REPLICATION; Or from MySQL 8.0.23: mysql>  STOP GROUP_REPLICATION; mysql>  CHANGE REPLICATION SOURCE TO PRIVILEGE_CHECKS_USER = ’gr_repl’@’%.example.com’  FOR CHANNEL ’group_replication_recovery’; mysql>  START GROUP_REPLICATION; 17.3.3.2 Privilege Checks For Group Replication Channels Replication Privilege Checks