log sequence number [...] is in the future!

Hello,

I try to use xtrabackup to create incremental backups on a test database.
Backups work with this commands :

innobackupex --user=backup --password=backup_password --use-memory=512M --no-lock --no-timestamp /root/work/backup/backup/16092014_150617_FULL

innobackupex --user=backup --password=backup_password --use-memory=512M --no-lock --no-timestamp --incremental /root/work/backup/backup/16092014_150711_INCR --incremental-basedir=/root/work/backup/backup/16092014_150617_FULL

innobackupex --user=backup --password=backup_password --use-memory=512M --no-lock --no-timestamp --incremental /root/work/backup/backup/16092014_150754_INCR --incremental-basedir=/root/work/backup/backup/16092014_150711_INCR

But I get an error in the preparation :

innobackupex --user=backup --password=backup_password --use-memory=512M --apply-log --redo-only /root/work/backup/backup/16092014_150617_FULL

innobackupex --user=backup --password=backup_password --use-memory=512M --apply-log --redo-only /root/work/backup/backup/16092014_150617_FULL --incremental-dir=/root/work/backup/backup/16092014_150711_INCR

innobackupex --user=backup --password=backup_password --use-memory=512M --apply-log --redo-only /root/work/backup/backup/16092014_150617_FULL --incremental-dir=/root/work/backup/backup/16092014_150754_INCR

innobackupex --user=backup --password=backup_password --use-memory=512M --apply-log /root/work/backup/backup/16092014_150617_FULL

[…]
[COLOR=#FF0000]2014-09-16 15:16:15 7f1bcf402720 InnoDB: Error: page 0 log sequence number 468352328
InnoDB: is in the future! Current system log sequence number 468343925.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: [url]http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]
InnoDB: for more information.
[…]

I have exactly the same error if I do :

innobackupex --user=backup --password=backup_password --use-memory=512M --no-lock --no-timestamp /root/work/backup/backup/16092014_150617_FULL

innobackupex --user=backup --password=backup_password --use-memory=512M --no-lock --no-timestamp --incremental /root/work/backup/backup/16092014_150711_INCR --incremental-basedir=/root/work/backup/backup/16092014_150617_FULL

innobackupex --user=backup --password=backup_password --use-memory=512M --no-lock --no-timestamp --incremental /root/work/backup/backup/16092014_150754_INCR --incremental-basedir=/root/work/backup/backup/16092014_150711_INCR

innobackupex --user=backup --password=backup_password --use-memory=512M --apply-log --redo-only /root/work/backup/backup/16092014_150617_FULL

innobackupex --user=backup --password=backup_password --use-memory=512M --apply-log --redo-only /root/work/backup/backup/16092014_150617_FULL --incremental-dir=/root/work/backup/backup/16092014_150711_INCR

innobackupex --user=backup --password=backup_password --use-memory=512M --apply-log /root/work/backup/backup/16092014_150617_FULL --incremental-dir=/root/work/backup/backup/16092014_150754_INCR

Did I forget a setting ? Does my backup is ok ?

Thank you in advance.

Hi brsysadmin

For future reference, Percona has a good guide for this here:
[url]Percona XtraBackup

Basic steps:

  1. Prepare the full backup (redo-only)
  2. Prepare the 1st incremental backup (redo-only)
  3. Prepare the 2nd incremental backup (normal; no redo-only)
  4. Prepare the full backup one last time (normal; no redo-only)

So I believe your first attempt was the closest; just remove the redo-only flag from the second incremental preparation, and then it should work. =)

-Scott

Hello,

I tried following this documentation and that’s ok.
However, when I prepare the first full backup, I get this message :

innobackupex --use-memory=512M --apply-log --redo-only /root/work/backup/backup/17092014_154041_FULL

[…]
InnoDB: Highest supported file format is Barracuda.
InnoDB: The log sequence numbers 369628192 and 369628192 in ibdata files do not match the log sequence number 369628202 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
[…]

Is this normal ?