2

I'm using innobackupex to backup my databases like this:

usr/local/bin/innobackupex  --user=bkpuser --password='example' --rsync \
--no-timestamp /pathtobackup 2> /pathtobackup/innobackupex.log

Now this page says "However there are transactions which are incomplete, and others which have not been flushed to their datafiles. In other words the backup as-is would be similar to a datadir if your database crashed. Some additional transactions must still be applied.".

Is this true? I thought that at least the flushing part was not true, and I'm not sure about the transactions. My goal is to be able to restore my database of course like it never went down, so please advice.

datadevil
  • 525
  • 1
  • 6
  • 22

1 Answers1

2

Short Version: if you are running backups against a busy server, then YES.
If you lock the server from updates, ie is a slave and do mysql -e "STOP SLAVE" before the backup, I suspect the xtrabackup_logfile would be empty and apply-log would do nothing.

Longish version:

There is a doc providing an example of making a backup and restoring it, as part of a howto on preparing a slave for replication, and that indicates that IT IS required to add a step to apply the logs before they are available for use;

innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir
innobackupex --user=yourDBuser --password=MaGiCdB1 /
       --apply-log /path/to/backupdir/$TIMESTAMP/

The options page for innobackupex indicate that --apply-log reads transactions from the xtrabackup_logfile

Prepare a backup in BACKUP-DIR by applying the transaction log file named xtrabackup_logfile located in the same directory. Also, create new transaction logs. The InnoDB configuration is read from the file backup-my.cnf created by innobackupex when the backup was made.

I suspect that xtrabackup_logfile contains the transactions during the period that the backup was running but the database was not locked. I think by this strategy that innobackupex can run with only a short lock time, and use the binlog to apply the updates to the backup retrospectively.

The xtrabackup-manager tool applies the log has a apply-log step in this file here;
http://code.google.com/searchframe#i12s1rWpN4M/trunk/includes/genericBackupTaker.class.php&q=apply%20log%20package:xtrabackup-manager.googlecode.com

Its not clear what format these files are (file xtrabackup_logfile returns "data"), though they seem to be sparse on my system, but I don't expecting any pending transaction in this case because the backups are taken from a stopped slave. Though if you wanted to find out, the source code of xtrabackup is available for inspection.

Tom
  • 10,886
  • 5
  • 39
  • 62