Thanks for clarifications. So the actual problem was that xtrabackup was using an incorrect InnoDB data files configuration.
When innobackupex is used to create backups, the server's innodb_data_file_path value is written to backup-my.cnf, but that file is not automatically used at prepare, it has to be specified explicitly via --defaults-file. And when innobackupex is not used, we simply don't have any information about data files configuration at prepare. Which causes problems like the one in this bug when there are multiple data files configured with innodb_data_file_path.
Until that BP is implemented, the workaround is to either use --defaults-file=backup-my.cnf (if that file is available), or specify innodb_data_file_path on the xtrabackup command line explicitly (when backup was taken without innobackupex) using the same value as it was on the server where the backup was taken.
Hi Bob,
Thanks for clarifications. So the actual problem was that xtrabackup was using an incorrect InnoDB data files configuration.
When innobackupex is used to create backups, the server's innodb_ data_file_ path value is written to backup-my.cnf, but that file is not automatically used at prepare, it has to be specified explicitly via --defaults-file. And when innobackupex is not used, we simply don't have any information about data files configuration at prepare. Which causes problems like the one in this bug when there are multiple data files configured with innodb_ data_file_ path.
There is a blueprint targeting this specific problem: https:/ /blueprints. launchpad. net/percona- xtrabackup/ +spec/backup- config- in-xtrabackup
Until that BP is implemented, the workaround is to either use --defaults- file=backup- my.cnf (if that file is available), or specify innodb_ data_file_ path on the xtrabackup command line explicitly (when backup was taken without innobackupex) using the same value as it was on the server where the backup was taken.