Spec-Zone .ru
спецификации, руководства, описания, API

7.5. Point-in-Time (Incremental) Recovery Using the Binary Log

7.5.1. Point-in-Time Recovery Using Event Times
7.5.2. Point-in-Time Recovery Using Event Positions

Point-in-time recovery refers to recovery of data changes made since a given point in time. Typically, this type of recovery is performed after restoring a full backup that brings the server to its state as of the time the backup was made. (The full backup can be made in several ways, such as those listed in Section 7.2, "Database Backup Methods".) Point-in-time recovery then brings the server up to date incrementally from the time of the full backup to a more recent time.

Point-in-time recovery is based on these principles:

If you have more than one binary log to execute 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:

shell> mysqlbinlog binlog.000001 | mysql -u root -p #
        DANGER!!shell> 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 CREATE TEMPORARY 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 "unknown table."

To avoid problems like this, use a single connection to execute the contents of all binary logs that you want to process. Here is one way to do so:

shell> mysqlbinlog binlog.000001 binlog.000002 |
        mysql -u root -p

Another approach is to write all the logs to a single file and then process the file:

shell> mysqlbinlog binlog.000001 >
        /tmp/statements.sqlshell> mysqlbinlog binlog.000002 >>
        /tmp/statements.sqlshell> mysql -u root -p -e "source
        /tmp/statements.sql"