4. LOAD DATA INFILE Statements
The LOAD DATA INFILE statement
makes it easy to fill tables quickly from a file.
Unfortunately, it is dependent on a certain kind of context that cannot
be covered by the context events we have discussed: files that need to
be read from the filesystem.
To handle LOAD DATA INFILE, the
MySQL server uses a special set of events to handle the transfer of the
file using the binary log. In addition to solving the problem for
LOAD DATA INFILE, this makes the
statement a very convenient tool for transferring large amounts of data
from the master to the slave, as you will see soon. To correctly
transfer and execute a LOAD DATA
INFILE statement, several new events are introduced:
Begin_load_query
This event starts to transfer data in the file.
Append_block
A sequence of one or more of these events follows the
Begin_load_query event to
contain the rest of the file’s data if the file was larger than
the maximum allowed packet size on the connection.
Execute_load_query
This event is a specialized variant of the Query event that contains the LOAD DATA INFILE statement executed on
the master.
Even though the statement contained in this event contains
the name of the file that was used on the master, this file will
not be sought by the slave. Instead, the contents provided by the
preceding Begin_load_query and
Append_block events will be
used.
For each LOAD DATA INFILE
statement executed on the master, the file to read is mapped to an
internal file-backed buffer, which is used in the following processing.
In addition, a unique file ID is assigned to the execution of the statement and
is used to refer to the file read by the statement.
While the statement is executing, the file contents are written to
the binary log as a sequence of events starting with a Begin_load_query event—which indicates the
beginning of a new file—followed by zero or more Append_block events. Each event written to the
binary log is no larger than the maximum allowed packet size, as
specified by the max-allowed-packet
option.
After the entire file is read and applied to the table, the
execution of the statement terminates by writing the Execute_load_query event to the binary log.
This event contains the statement executed together with the file ID
assigned to the execution of the statement. Note that the statement is
not the original statement as the user wrote it, but rather a re-created
version of the statement.
Note:
If you are reading an old binary log, you might instead find
Load_log_event, Execute_log_event, and Create_file_log_event. These were the events
used to replicate LOAD DATA INFILE
prior to MySQL version 5.0.3 and were replaced by the implementation
described above.
Example 3 shows
the events written to the binary log by a successful execution of a
LOAD DATA INFILE statement. In the
Info field, you can see the assigned
file ID—1 in this case—and see that it is used for all the events that
are part of the execution of the statement. You can also see that the
file foo.dat used by the statement
contains more than the maximum allowed packet size of 16384, so it is
split into three events.
Example 3. Successful execution of a LOAD DATA INFILE
master> SHOW BINLOG EVENTS IN 'master-bin.000042' FROM 269\G
*************************** 1. row ***************************
Log_name: master-bin.000042
Pos: 269
Event_type: Begin_load_query
Server_id: 1
End_log_pos: 16676
Info: ;file_id=1;block_len=16384
*************************** 2. row ***************************
Log_name: master-bin.000042
Pos: 16676
Event_type: Append_block
Server_id: 1
End_log_pos: 33083
Info: ;file_id=1;block_len=16384
*************************** 3. row ***************************
Log_name: master-bin.000042
Pos: 33083
Event_type: Append_block
Server_id: 1
End_log_pos: 33633
Info: ;file_id=1;block_len=527
*************************** 4. row ***************************
Log_name: master-bin.000042
Pos: 33633
Event_type: Execute_load_query
Server_id: 1
End_log_pos: 33756
Info: use `test`; LOAD DATA LOCAL INFILE 'foo.dat' INTO ... ;file_id=1
4 rows in set (0.00 sec)
|