This section explains the general idea of using the binary log to perform a point-in-time-recovery. The next section, Section 7.5.2, “Point-in-Time Recovery Using Event Positions”, explains the operation in details with an example.
Many of the examples in this and the next section use the
mysql client to process binary log output
produced by mysqlbinlog. If your binary log
\0 (null) characters, that output
cannot be parsed by mysql unless you invoke
it with the
The source of information for point-in-time recovery is the set of binary log files generated subsequent to the full backup operation. Therefore, to allow a server to be restored to a point-in-time, binary logging must be enabled on it (see Section 5.4.4, “The Binary Log” for details).
To restore data from the binary log, you must know the name and
location of the current binary log files. By default, the server
creates binary log files in the data directory, but a path name
can be specified with the
--log-bin option to place the
files in a different location. To see a listing of all binary
log files, use this statement:
mysql> SHOW BINARY LOGS;
To determine the name of the current binary log file, issue the following statement:
mysql> SHOW MASTER STATUS;
The mysqlbinlog utility converts the events in the binary log files from binary format to text so that they can be viewed or applied. mysqlbinlog has options for selecting sections of the binary log based on event times or position of events within the log. See Section 4.6.7, “mysqlbinlog — Utility for Processing Binary Log Files”.
Applying events from the binary log causes the data modifications they represent to be reexecuted. This enables recovery of data changes for a given span of time. To apply events from the binary log, process mysqlbinlog output using the mysql client:
$> mysqlbinlog binlog_files | mysql -u root -p
Viewing log contents can be useful when you need to determine event times or positions to select partial log contents prior to executing events. To view events from the log, send mysqlbinlog output into a paging program:
$> mysqlbinlog binlog_files | more
Alternatively, save the output in a file and view the file in a text editor:
$> mysqlbinlog binlog_files > tmpfile $> ... edit tmpfile ...
Saving the output in a file is useful as a preliminary to
executing the log contents with certain events removed, such as
DROP TABLE. You can
delete from the file any statements not to be executed before
executing its contents. After editing the file, apply the
contents as follows:
$> mysql -u root -p < tmpfile
If you have more than one binary log to apply on the MySQL server, the safe method is to process them all using a single connection to the server. Here is an example that demonstrates what may be unsafe:
$> mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!! $> mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!
Processing binary logs this way using different connections to
the server causes problems if the first log file contains a
TABLE statement and the second log contains a
statement that uses the temporary table. When the first
mysql process terminates, the server drops
the temporary table. When the second mysql
process attempts to use the table, the server reports
To avoid problems like this, use a single connection to apply the contents of all binary log files that you want to process. Here is one way to do so:
$> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p
Another approach is to write the whole log to a single file and then process the file:
$> mysqlbinlog binlog.000001 > /tmp/statements.sql $> mysqlbinlog binlog.000002 >> /tmp/statements.sql $> mysql -u root -p -e "source /tmp/statements.sql"
When writing to a dump file while reading back from a binary log
containing GTIDs (see Section 16.1.3, “Replication with Global Transaction Identifiers”), use
--skip-gtids option with
mysqlbinlog, like this:
$> mysqlbinlog --skip-gtids binlog.000001 > /tmp/dump.sql $> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql $> mysql -u root -p -e "source /tmp/dump.sql"