The user account that is specified as the
PRIVILEGE_CHECKS_USER account for a
replication channel must have the
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
strongly recommended for replication channels that are secured
PRIVILEGE_CHECKS_USER account, and
will be required in a future release. With statement-based
binary logging, some administrator-level privileges are
required to execute transactions successfully.
explicitly or implicitly allows the
PRIVILEGE_CHECKS_USER account to carry out
the following operations that a replication thread needs to
Setting the value of the system variables
pseudo_slave_mode, to apply appropriate metadata and behaviors when executing transactions.
Updating the system tables
mysql.slave_master_info, to update replication metadata. (If events access these tables explicitly for other purposes, you must grant the appropriate privileges on the tables.)
Applying a binary log
Table_map_log_event, which provides table metadata but does not make any database changes.
PRIVILEGE_CHECKS_USER account needs the
in order to change the value of certain system variables
the duration of a session to carry out replication operations.
This privilege also allows the account to apply
mysqlbinlog output that was created using the
If table encryption is in use, the
system variable is set to
ON, and the
encryption setting for the tablespace involved in any event
differs from the applying server's default encryption setting
(specified by the
privilege in order to override the default encryption setting.
It is strongly recommended that you do not grant this privilege.
Instead, ensure that the default encryption setting on a
replication slave matches the encryption status of the
tablespaces that it replicates, and that replication group
members have the same default encryption setting, so that the
privilege is not needed.
In order to execute specific replicated transactions from the
relay log, or transactions from mysqlbinlog
output as required, the
account must have the following privileges:
For a row insertion logged in row format (which are logged as a
INSERTprivilege on the relevant table.
For a row update logged in row format (which are logged as an
UPDATEprivilege on the relevant table.
For a row deletion logged in row format (which are logged as a
DELETEprivilege on the relevant table.
For a transaction control statement such as
COMMITor DML logged in statement format (which are logged as a
Query_log_event), privileges to execute the statement contained in the event.
INFILE operations need to be carried out on the
replication channel, use row-based binary logging
LOAD DATA is considered unsafe
for statement-based format, and the
PRIVILEGE_CHECKS_USER account should not be
given the required privilege to execute such a statement (the
FILE privilege). For more
Section 220.127.116.11, “Replication and LOAD DATA”. The
Format_description_log_event, which deletes
any temporary files created by
DATA events, is processed without privilege checks.
variable is set to specify one or more SQL statements to be
executed when the 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
DROP ROLE, and
GRANT OPTION, and do not permit
the account to update the
With these privileges, the account could be used to create or
modify user accounts on the server. To avoid ACL statements
issued on the master being replicated to the secured channel for
execution (where they will fail in the absence of these
privileges), you can issue
SET sql_log_bin =
0 before all ACL statements and
sql_log_bin = 1 after them, to omit the statements
from the master'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 slave.