<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="replication-privilege-checks-account">
      </a>
      19.3.3.1 Privileges For The Replication PRIVILEGE_CHECKS_USER Account
     </h4>
    </div>
   </div>
  </div>
  <p>
   The user account that is specified using the
   <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
    <code class="literal">
     CHANGE REPLICATION SOURCE TO
    </code>
   </a>
   statement as the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account for a replication channel must have the
   <a class="link" href="privileges-provided.html#priv_replication-applier">
    <code class="literal">
     REPLICATION_APPLIER
    </code>
   </a>
   privilege,
        otherwise the replication applier thread does not start. As
        explained in
   <a class="xref" href="replication-privilege-checks.html" title="19.3.3 Replication Privilege Checks">
    Section 19.3.3, “Replication Privilege Checks”
   </a>
   , 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.
  </p>
  <p>
   The use of row-based binary logging
        (
   <a class="link" href="replication-options-binary-log.html#sysvar_binlog_format">
    <code class="literal">
     binlog_format=ROW
    </code>
   </a>
   ) is strongly
        recommended for replication channels that are secured using a
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account. With
        statement-based binary logging, some administrator-level
        privileges might be required for the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account to execute
        transactions successfully. The
   <code class="literal">
    REQUIRE_ROW_FORMAT
   </code>
   setting can be applied to
        secured channels, which restricts the channel from executing
        events that would require these privileges.
  </p>
  <p>
   The
   <a class="link" href="privileges-provided.html#priv_replication-applier">
    <code class="literal">
     REPLICATION_APPLIER
    </code>
   </a>
   privilege
        explicitly or implicitly allows the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account to carry out
        the following operations that a replication thread needs to
        perform:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      Setting the value of the system variables
      <a class="link" href="replication-options-gtids.html#sysvar_gtid_next">
       <code class="literal">
        gtid_next
       </code>
      </a>
      ,
      <a class="link" href="replication-options-binary-log.html#sysvar_original_commit_timestamp">
       <code class="literal">
        original_commit_timestamp
       </code>
      </a>
      ,
      <a class="link" href="replication-options-source.html#sysvar_original_server_version">
       <code class="literal">
        original_server_version
       </code>
      </a>
      ,
      <a class="link" href="replication-options-source.html#sysvar_immediate_server_version">
       <code class="literal">
        immediate_server_version
       </code>
      </a>
      ,
            and
      <a class="link" href="server-system-variables.html#sysvar_pseudo_replica_mode">
       <code class="literal">
        pseudo_replica_mode
       </code>
      </a>
      , to
            apply appropriate metadata and behaviors when executing
            transactions.
     </p>
    </li>
    <li class="listitem">
     <p>
      Executing internal-use
      <a class="link" href="binlog.html" title="15.7.8.1 BINLOG Statement">
       <code class="literal">
        BINLOG
       </code>
      </a>
      statements to apply
      <a class="link" href="mysqlbinlog.html" title="6.6.9 mysqlbinlog — Utility for Processing Binary Log Files">
       <span class="command">
        <strong>
         mysqlbinlog
        </strong>
       </span>
      </a>
      output,
            provided that the account also has permission for the tables
            and operations in those statements.
     </p>
    </li>
    <li class="listitem">
     <p>
      Updating the system tables
      <code class="literal">
       mysql.gtid_executed
      </code>
      ,
      <code class="literal">
       mysql.slave_relay_log_info
      </code>
      ,
      <code class="literal">
       mysql.slave_worker_info
      </code>
      , and
      <code class="literal">
       mysql.slave_master_info
      </code>
      , to update
            replication metadata. (If events access these tables
            explicitly for other purposes, you must grant the
            appropriate privileges on the tables.)
     </p>
    </li>
    <li class="listitem">
     <p>
      Applying a binary log
      <code class="literal">
       Table_map_log_event
      </code>
      , which provides table
            metadata but does not make any database changes.
     </p>
    </li>
   </ul>
  </div>
  <p>
   If the
   <code class="literal">
    REQUIRE_TABLE_PRIMARY_KEY_CHECK
   </code>
   option
        of the
   <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
    <code class="literal">
     CHANGE REPLICATION SOURCE
        TO
    </code>
   </a>
   statement is set to the default value
   <code class="literal">
    STREAM
   </code>
   , the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account needs
        privileges sufficient to set restricted session variables, so
        that it can change the value of the
   <a class="link" href="server-system-variables.html#sysvar_sql_require_primary_key">
    <code class="literal">
     sql_require_primary_key
    </code>
   </a>
   system
        variable for the duration of a session to match the setting
        replicated from the source. The
   <a class="link" href="privileges-provided.html#priv_session-variables-admin">
    <code class="literal">
     SESSION_VARIABLES_ADMIN
    </code>
   </a>
   privilege
        gives the account this capability. This privilege also allows
        the account to apply
   <a class="link" href="mysqlbinlog.html" title="6.6.9 mysqlbinlog — Utility for Processing Binary Log Files">
    <span class="command">
     <strong>
      mysqlbinlog
     </strong>
    </span>
   </a>
   output that
        was created using the
   <a class="link" href="mysqlbinlog.html#option_mysqlbinlog_disable-log-bin">
    <code class="option">
     --disable-log-bin
    </code>
   </a>
   option. If
        you set
   <code class="literal">
    REQUIRE_TABLE_PRIMARY_KEY_CHECK
   </code>
   to
        either
   <code class="literal">
    ON
   </code>
   or
   <code class="literal">
    OFF
   </code>
   , the
        replica always uses that value for the
   <a class="link" href="server-system-variables.html#sysvar_sql_require_primary_key">
    <code class="literal">
     sql_require_primary_key
    </code>
   </a>
   system
        variable in replication operations, and so does not need these
        session administration level privileges.
  </p>
  <p>
   If table encryption is in use, the
   <a class="link" href="server-system-variables.html#sysvar_table_encryption_privilege_check">
    <code class="literal">
     table_encryption_privilege_check
    </code>
   </a>
   system variable is set to
   <code class="literal">
    ON
   </code>
   , and the
        encryption setting for the tablespace involved in any event
        differs from the applying server's default encryption setting
        (specified by the
   <a class="link" href="server-system-variables.html#sysvar_default_table_encryption">
    <code class="literal">
     default_table_encryption
    </code>
   </a>
   system
        variable), the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account
        needs the
   <a class="link" href="privileges-provided.html#priv_table-encryption-admin">
    <code class="literal">
     TABLE_ENCRYPTION_ADMIN
    </code>
   </a>
   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 replica
        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.
  </p>
  <p>
   In order to execute specific replicated transactions from the
        relay log, or transactions from
   <a class="link" href="mysqlbinlog.html" title="6.6.9 mysqlbinlog — Utility for Processing Binary Log Files">
    <span class="command">
     <strong>
      mysqlbinlog
     </strong>
    </span>
   </a>
   output as required, the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account must have the following privileges:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      For a row insertion logged in row format (which are logged
            as a
      <code class="literal">
       Write_rows_log_event
      </code>
      ), the
      <a class="link" href="privileges-provided.html#priv_insert">
       <code class="literal">
        INSERT
       </code>
      </a>
      privilege on the
            relevant table.
     </p>
    </li>
    <li class="listitem">
     <p>
      For a row update logged in row format (which are logged as
            an
      <code class="literal">
       Update_rows_log_event
      </code>
      ), the
      <a class="link" href="privileges-provided.html#priv_update">
       <code class="literal">
        UPDATE
       </code>
      </a>
      privilege on the
            relevant table.
     </p>
    </li>
    <li class="listitem">
     <p>
      For a row deletion logged in row format (which are logged as
            a
      <code class="literal">
       Delete_rows_log_event
      </code>
      ), the
      <a class="link" href="privileges-provided.html#priv_delete">
       <code class="literal">
        DELETE
       </code>
      </a>
      privilege on the
            relevant table.
     </p>
    </li>
   </ul>
  </div>
  <p>
   If statement-based binary logging is in use (which is not
        recommended with a
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account), for a transaction control statement such as
   <code class="literal">
    BEGIN
   </code>
   or
   <code class="literal">
    COMMIT
   </code>
   or DML
        logged in statement format (which are logged as a
   <code class="literal">
    Query_log_event
   </code>
   ), the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account needs
        privileges to execute the statement contained in the event.
  </p>
  <p>
   If
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   operations need to
        be carried out on the replication channel, use row-based binary
        logging (
   <a class="link" href="replication-options-binary-log.html#sysvar_binlog_format">
    <code class="literal">
     binlog_format=ROW
    </code>
   </a>
   ).
        With this logging format, the
   <a class="link" href="privileges-provided.html#priv_file">
    <code class="literal">
     FILE
    </code>
   </a>
   privilege is not needed to
        execute the event, so do not give the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account this privilege.
        The use of row-based binary logging is strongly recommended with
        replication channels that are secured using a
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account. If
   <code class="literal">
    REQUIRE_ROW_FORMAT
   </code>
   is set for the channel,
        row-based binary logging is required. The
   <code class="literal">
    Format_description_log_event
   </code>
   , which deletes
        any temporary files created by
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD
        DATA
    </code>
   </a>
   events, is processed without privilege checks.
        For more information, see
   <a class="xref" href="replication-features-load-data.html" title="19.5.1.19 Replication and LOAD DATA">
    Section 19.5.1.19, “Replication and LOAD DATA”
   </a>
   .
  </p>
  <p>
   If the
   <a class="link" href="replication-options-replica.html#sysvar_init_replica">
    <code class="literal">
     init_replica
    </code>
   </a>
   system
        variable is set to specify one or more SQL statements to be
        executed when the replication SQL thread starts, the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account must have the
        privileges needed to execute these statements.
  </p>
  <p>
   It is recommended that you never give any ACL privileges to the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account, including
   <a class="link" href="privileges-provided.html#priv_create-user">
    <code class="literal">
     CREATE USER
    </code>
   </a>
   ,
   <a class="link" href="privileges-provided.html#priv_create-role">
    <code class="literal">
     CREATE ROLE
    </code>
   </a>
   ,
   <a class="link" href="privileges-provided.html#priv_drop-role">
    <code class="literal">
     DROP ROLE
    </code>
   </a>
   , and
   <a class="link" href="privileges-provided.html#priv_grant-option">
    <code class="literal">
     GRANT OPTION
    </code>
   </a>
   , and do not permit
        the account to update the
   <code class="literal">
    mysql.user
   </code>
   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
   <code class="literal">
    SET sql_log_bin =
        0
   </code>
   before all ACL statements and
   <code class="literal">
    SET
        sql_log_bin = 1
   </code>
   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
        (
   <a class="link" href="replication-options-binary-log.html#option_mysqld_binlog-ignore-db">
    <code class="option">
     --binlog-ignore-db
    </code>
   </a>
   ) to filter
        out this database on the replica.
  </p>
 </div>
 <br/>
</div>
