xtrabackup 2.3 behavior changes

[Ryan Brothers]

I upgraded to xtrabackup 2.3 and my automated scripts are throwing errors in the new version. I believe it's because innobackupex has been merged into xtrabackup, but is there a way to re-create the old behavior? My scripts run xtrabackup directly without going through innobackupex such as:

xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/data/backups/mysql

My issues are:

1) xtrabackup now requires a username/password to run. It previously ran backups without needing this. Is there a reason a username/password is now needed or is there a benefit to supplying it? The documentation doesn't mention a username/password at https://www.percona.com/doc/percona-xtrabackup/2.3/xtrabackup_bin/creating_a_backup.html.

2) I use xtrabackup to backup specific tables and then restore them by following the instructions at https://www.percona.com/doc/percona-xtrabackup/2.3/xtrabackup_bin/restoring_individual_tables.html. In version 2.2, an .ibd file would be backed up for each table. Now I'm seeing an .ibd and a .frm file for each table. Is there a way to only backup the .ibd file like xtrabackup used to do? Or does the documentation need to be updated on the above page to say that a .frm file will be created, but it should be ignored and not copied into the "destination server's data directory"?

[Sergei Glushchenko (sergei.glushchenko)]

Hi Ryan,

Thank you for detailed report. Yes, innobackupex has been merged into xtrabackup with the intention to get rid of innobackupex and make xtrabackup to do all the things that innobackupex previously did. It means that xtrabackup does now copy all the files (InnoDB, MyISAM, FRM, etc.), it takes care of binary log coordinates, and so on. It was intentional, but our fault that that we did not document this behavior properly.

As for the case when you need to copy only InnoDB tables, we might consider implementing such mode. Note, that we never recommended to xtrabackup directly.

[Ryan Brothers (ryan-brothers)]

Sergei,

Thanks for your quick response back. Yes, I am only using InnoDB tables in my environment and I only need to backup the data. I am backing up the table structure and procedures/functions by running mysqldump --no-data --routines.

The reason I went this approach is because I need to restore individual tables and I believe the only way to do that is by creating the table structure manually, so I had to do the mysqldump anyway to get the table structure and procedures/functions. I felt it was more efficient to use xtrabackup directly rather than going through innobackupex as I didn't need the .frm files and the extra functionality of innobackupex. Is that correct or is there a way to do a partial restore using .frm files?

Also, about the binary logs, I was able to get the binary log position using xtrabackup 2.2 as it created a file xtrabackup_binlog_pos_innodb. In 2.3, I'm seeing 2 files created both with the same content, xtrabackup_binlog_pos_innodb and xtrabackup_binlog_info.

Thanks again for your help.

Ryan

[Hrvoje Matijakovic (hrvojem)]

https://github.com/percona/percona-xtrabackup/pull/285
https://github.com/percona/percona-xtrabackup/pull/286

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-440