Problem Description
Erroneous deletion of data, statistics of data before a certain point in time (without a timestamp field), etc. There are many scenarios that require us to restore data to a specific point in time.
The notes in this article will record the method of restoring data to a specific point in time .
Solution
Method: Restore the data to a specific point in time: (1) Either you have a backup created at that point in time; (2) Either you need to know the SQL statement execution history and perform SQL replay based on the previous backup.
Contrast: For (1) method, it is not universal, and it is difficult to predict which time point data will be needed in the future. We usually use the (2) method, based on the existing backup, using binlog to replay.
Supplement: Of course, in addition to binlog, as long as there is SQL execution history, it can be used for replay in theory.
mysqldump + binlog
Process: Import the backup created with mysqldump into the database, and then perform binlog replay.
Requirement: For backup using mysqldump, you need to record the binlog location when creating the backup to specify the location during replay.
XtraBackup + binlog
Process: Import the backup created with Xtrabackup into the database, and then perform binlog replay.
Supplement: For backup using XtraBackup, the binlog location is saved in the backup directory, and the data can be restored directly.
Use XtraBackup + binlog to restore
Prerequisites and precautions
1) Have historical backup data as the basis for binlog replay;
2) Include the modification history of many databases in binlog, and pay attention to filtering to prevent affecting other databases;
The first step, use backup and restore
Use Xtrabackup to recover data, the data recovery process will not be repeated.
The second step, determine the scope of replay (key step)
Check the current binlog file status of the database to confirm that the binlog file we are about to use still exists:
mysql> SHOW BINARY LOGS; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000001 | 126 | | mysql-bin.000002 | 1306 | | mysql-bin.000003 | 126 | | mysql-bin.000004 | 497 | +------------------+-----------+
View the binlog file (File) currently in use:
mysql> SHOW MASTER STATUS; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000004 | 497 | | | +------------------+----------+--------------+------------------+
Check the location of binlog when XtraBackup was created:
# cat /path/to/backup/xtrabackup_binlog_info mysql-bin.000003 57
Now we need to determine the end time point of data recovery (before the data is destroyed):
# We need to pay attention to the history between mysql-bin.000003 and mysql-bin.000004
mysqlbinlog "/path/to/datadir/mysql-bin.000003" "/path/to/datadir/mysql-bin.000004" \
--start-position=57> mybinlog.sql
Through the above steps, the playback start position and end time can be determined , and then the playback can be performed.
The third step is to replay history
#!/bin/sh
mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 --stop-datetime="11-12-25 01:00:00" | mysql -u root -p
related articles
"XtraBackup"-"Prepare" operation of backup data
"MySQL" -Use mysqldump for data backup and recovery (migration)
"XtraBackup"-Backup instance and instance recovery