LOAD DATA
被认为是不安全的对statement-based日志记录(seeSection 17.2.1.3, “Determination of Safe and Unsafe Statements in Binary Logging”). Whenbinlog_format=MIXED
is set, the statement is logged in row-based format. Whenbinlog_format=STATEMENT
is set, note thatLOAD DATA
does not generate a warning, unlike other unsafe statements.
If you useLOAD DATA
withbinlog_format=STATEMENT
, each replica on which the changes are to be applied creates a temporary file containing the data. The replica then uses aLOAD 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 aPRIVILEGE_CHECKS_USER
account has been used to help secure the replication channel (seeSection 17.3.3, “Replication Privilege Checks”), it is strongly recommended that you logLOAD DATA
operations using row-based binary logging (binlog_format=ROW
). IfREQUIRE_ROW_FORMAT
is set for the channel, row-based binary logging is required. With this logging format, theFILE
privilege is not needed to execute the event, so do not give thePRIVILEGE_CHECKS_USER
account this privilege. If you need to recover from a replication error involving aLOAD DATA INFILE
operation logged in statement format, and the replicated event is trusted, you could grant theFILE
privilege to thePRIVILEGE_CHECKS_USER
account temporarily, removing it after the replicated event has been applied.
Whenmysqlbinlogreads log events forLOAD DATA
statements logged in statement-based format, a generated local file is created in a temporary directory. These temporary files are not automatically removed bymysqlbinlogor any other MySQL program. If you do useLOAD 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, seeSection 4.6.9, “mysqlbinlog — Utility for Processing Binary Log Files”.