TODO: Use xtrabackup_binary file to select version of xtrabackup and

[GoogleCodeExporter]

7) choosing xtrabackup binary should be automatic.
It disturbs me that you have to define the mysql_type_id in
scheduled_backups. innobackupex figures the mysql version out
automatically, and stores it in a file xtrabackup_binary that is
stored in the backup directory (along with other meta data such as
checkpoints, binlog_info...). From there you can find out the correct
xtrabackup binary to use in following steps (like for --prepare).

 - identifying mysql version and using correct xtrabackup binary
should be transparent to end user.
 - when applying logs and doing incremental backups one should use the
same xtrabackup binary using the information recorded in
xtrabackup_binary.
 - when doing incremental backups, we should check the mysqld version (xtrabackup doesn't do/need this?) and assert that it is the same as it was for the full backup.
 - If minor version of mysqld has changed, emit warning but allow backup to proceed. If major version has changed, the incremental backup should abort and fail - user is required to start fresh from a full backup in such case.
 - note that storing mysql version into the backup meta data is actually a good innobackupex feature and we could contribute it there instead of inside XBM.

Original issue reported on code.google.com by henrik.i...@gmail.com on 31 Mar 2011 at 8:50

[GoogleCodeExporter]

The complication here is that innobackupex script will detect which binary to 
use just fine, but when we run apply log only and incremental backups we need 
to know the correct binary for XBM to pick. We'd need to emulate this detection.

For now the simplest way to do this is to be able to hard configure it.

I agree in the future we should emulate the detection used by innobackupex and 
just figure it out ourselves.. meanwhile though, i have noticed that there are 
some cases where my backups will only work with a specific binary and it is not 
always the recommended one.

I'd say the best of both worlds is:

if mysql_type_id is NULL, use autodetect algorithm
else use binary for specified mysql_type

Original comment by lachlan....@gmail.com on 21 May 2011 at 12:02

[GoogleCodeExporter]

I forgot to note also that xtrabackup_binary file doesn't seem to get copied 
through when streaming the backup for some reason.

Original comment by lachlan....@gmail.com on 21 May 2011 at 12:05

[GoogleCodeExporter]

I can test again, but I'm pretty sure it got copied when I tried. Are you still 
using an old version of xtrabackup?

Original comment by henrik.i...@gmail.com on 21 May 2011 at 6:24

[GoogleCodeExporter]

I'm using xtrabackup 1.6 at the moment.

Original comment by lachlan....@gmail.com on 23 May 2011 at 4:20

[GoogleCodeExporter]

You're right. It's not there in my test backups either. I'll look into 
innobackupex script to see why some of the files get into the stream and some 
don't.

Original comment by henrik.i...@gmail.com on 28 May 2011 at 8:41

[GoogleCodeExporter]

Original comment by lachlan....@gmail.com on 22 Nov 2011 at 11:01

• Added labels: Priority-Low, Type-Enhancement