<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="replication-features-load-data">
      </a>
      19.5.1.19 Replication and LOAD DATA
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045135393328">
  </a>
  <a class="indexterm" name="idm46045135391840">
  </a>
  <p>
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   is considered unsafe
        for statement-based logging (see
   <a class="xref" href="replication-rbr-safe-unsafe.html" title="19.2.1.3 Determination of Safe and Unsafe Statements in Binary Logging">
    Section 19.2.1.3, “Determination of Safe and Unsafe Statements in Binary Logging”
   </a>
   ). When
   <a class="link" href="replication-options-binary-log.html#sysvar_binlog_format">
    <code class="literal">
     binlog_format=MIXED
    </code>
   </a>
   is set, the
        statement is logged in row-based format. When
   <a class="link" href="replication-options-binary-log.html#sysvar_binlog_format">
    <code class="literal">
     binlog_format=STATEMENT
    </code>
   </a>
   is set,
        note that
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   does not
        generate a warning, unlike other unsafe statements.
  </p>
  <p>
   If you use
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   with
   <a class="link" href="replication-options-binary-log.html#sysvar_binlog_format">
    <code class="literal">
     binlog_format=STATEMENT
    </code>
   </a>
   , each
        replica on which the changes are to be applied creates a
        temporary file containing the data. The replica then uses a
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   statement to apply the
        changes. This temporary file is not encrypted, even if binary
        log encryption is active on the source, If encryption is
        required, use row-based or mixed binary logging format instead,
        for which replicas do not create the temporary file.
  </p>
  <p>
   If a
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account has been
        used to help secure the replication channel (see
   <a class="xref" href="replication-privilege-checks.html" title="19.3.3 Replication Privilege Checks">
    Section 19.3.3, “Replication Privilege Checks”
   </a>
   ), it is strongly
        recommended that you log
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD
        DATA
    </code>
   </a>
   operations using row-based binary logging
        (
   <a class="link" href="replication-options-binary-log.html#sysvar_binlog_format">
    <code class="literal">
     binlog_format=ROW
    </code>
   </a>
   ). If
   <code class="literal">
    REQUIRE_ROW_FORMAT
   </code>
   is set for the channel,
        row-based binary logging is required. 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.
        If you need to recover from a replication error involving a
   <code class="literal">
    LOAD DATA INFILE
   </code>
   operation logged in
        statement format, and the replicated event is trusted, you could
        grant the
   <a class="link" href="privileges-provided.html#priv_file">
    <code class="literal">
     FILE
    </code>
   </a>
   privilege to the
   <code class="literal">
    PRIVILEGE_CHECKS_USER
   </code>
   account temporarily,
        removing it after the replicated event has been applied.
  </p>
  <p>
   When
   <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>
   reads log events for
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   statements logged in
        statement-based format, a generated local file is created in a
        temporary directory. These temporary files are not automatically
        removed by
   <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>
   or any other MySQL
        program. If you do use
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   statements with statement-based binary logging, you should
        delete the temporary files yourself after you no longer need the
        statement log. For more information, see
   <a class="xref" href="mysqlbinlog.html" title="6.6.9 mysqlbinlog — Utility for Processing Binary Log Files">
    Section 6.6.9, “mysqlbinlog — Utility for Processing Binary Log Files”
   </a>
   .
  </p>
 </div>
 <br/>
</div>
