Using MySQL Enterprise Backup and the binary
log files included by default in the incremental backups it
creates (except when they are created with the
--use-tts option), you can restore your
database to its state at an arbitrary time
tR in between a full
backup and an incremental backup or in between two incremental
backups. To do so:
Binary logging must be enabled in MySQL before taking the full backup that serves as the base for this restore operation.
Using the full and incremental backups that were created before
tR, restore the database to a time as close to
tRas possible and note that time (let us call it
tLB). Make sure the restored database is in a consistent state. This can be achieved by, for example, using the
copy-back-and-apply-logcommand for backup restore.
Roll forward the database to its state at the desired time
tRusing the binary log file[s] included in the incremental backup that covers
tR. Use the mysqlbinlog utility to extract from the binary log file[s] all the SQL activities that happened in between the
tLB(which you noted in step 2 above) and
tR, specifying those times with the
--stop-datetimeoptions, and pipe the output to the mysql client, to be replayed on the server:
mysqlbinlog --start-datetime="tLB" \ --stop-datetime="tR" \ binlog.000005 binlog.000006 binlog.000007 | mysql -u root -p
An alternative is to identify the beginning and endpoint of the extraction not by the start and stop times, but by their corresponding binary log positions:
mysqlbinlog --start-position="binary-log-position-corresponding-to-tLB" \ --stop-position="binary-log-position-corresponding-to-tR" \ binlog.000005 binlog.000006 binlog.000007 | mysql -u root -p
Note that you need to pipe all the binary log files in a single connection to the server. You can also dump all the SQL activities to a single file first, and then pipe or play the file to the mysql client.
For more tips on using the binary log for point-in-time recovery, see Point-in-Time (Incremental) Recovery Using the Binary Log.