LOAD DATA is considered unsafe
        for statement-based logging (see
        Section 5.1.3, “Determination of Safe and Unsafe Statements in Binary Logging”). When
        binlog_format=MIXED is set, the
        statement is logged in row-based format. When
        binlog_format=STATEMENT is set,
        note that LOAD DATA does not
        generate a warning, unlike other unsafe statements.
      
        If you use LOAD DATA with
        binlog_format=STATEMENT, each
        replica on which the changes are to be applied creates a
        temporary file containing the data. The replica then uses a
        LOAD DATA 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.
      
        If a PRIVILEGE_CHECKS_USER account has been
        used to help secure the replication channel (see
        Replication Privilege Checks), it is strongly
        recommended that you log LOAD
        DATA operations using row-based binary logging
        (binlog_format=ROW). If
        REQUIRE_ROW_FORMAT is set for the channel,
        row-based binary logging is required. 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.
        If you need to recover from a replication error involving a
        LOAD DATA INFILE operation logged in
        statement format, and the replicated event is trusted, you could
        grant the FILE privilege to the
        PRIVILEGE_CHECKS_USER account temporarily,
        removing it after the replicated event has been applied.
      
        When mysqlbinlog reads log events for
        LOAD DATA statements logged in
        statement-based format, a generated local file is created in a
        temporary directory. These temporary files are not automatically
        removed by mysqlbinlog or any other MySQL
        program. If you do use LOAD DATA
        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
        mysqlbinlog — Utility for Processing Binary Log Files.