Hi,
I mistakenly (perhaps) specified the wrong xtrabackup binary
when preparing a backup, but it appears to have worked okay.
I do not see any problems, but want to know what the issues
might be when using ibbacbk=xtrabackup_51 during a prepare of
a 5.5 backup.
Note that I had tried a similar prepare using the correct
binary, but that one had exited with an error.
Some details:
I took a compressed backup on a v5.5.19 (oracle) server using
innobackupex (v1.5.1) and xtrabackup (v1.6.6):
innobackupex --no-timestamp --slave-info --tmpdir=“$basepath” --stream=tar “$backuppath” | gzip > “$zipfile”
I then restored it to another machine. I ran the prepare:
innobackupex-1.5.1 --apply-log --defaults-file=/datadir/backup-my.cnf --ibbackup=/usr/bin/xtrabackup_55 /datadir
It started okay then exited with an error:
InnoDB: Log scan progressed past the checkpoint lsn 4224059527250
InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files…
InnoDB: Error: trying to add tablespace 75776 of name ‘./Somedatabase/old_table.ibd’
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 75776 of name ‘./Somedatabase/atable.ibd’ already exists in the tablespace
InnoDB: memory cache!
innobackupex-1.5.1: Error:
innobackupex-1.5.1: ibbackup failed at /usr/bin/innobackupex-1.5.1 line 349.
Note that the backup set included the file xtrabackup_binary,
and xtrabackup_55 was listed there. This file had not been
copied to the restored machine.
We have some 5.0 instances, and for those, when taking the
backup, the default choice for the xtrabackup binary is
xtrabackup_51.
Confusing the versions, I tried the 51 binary (on another
similar machine with fresh copy of backup set):
innobackupex-1.5.1 --apply-log --defaults-file=/datadir/backup-my.cnf --ibbackup=/usr/bin/xtrabackup_51 /datadir
It printed the first lines above, but after the line:
InnoDB: 75776 of name ‘./Somedatabase/atable.ibd’ already exists in the tablespace
InnoDB: memory cache!
It continued with:
InnoDB: Doing recovery: scanned up to log sequence number 983 2111918080 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 983 2117160960 (0 %)
…
and so on for quite a while. At the end, it printed the usual
innobackupex: completed OK!