Attempting to restore table from xtrabackup (v2.2.11)

MySQL & MariaDB Percona XtraBackup
1

So I have a backup I’m trying to restore into a new environment, but every time I attempt to prepare the backup for restoration, the defaults file in the backup location is ignored, and there is an error that the innodb_data_file_path parameter is not there. I figured this was related to permissions, as it is world-writable on a cifs share, and so copied it off to my pwd. However, the error is the same, except that it is now showing the same error but with the new defaults file name in it instead. The file I set as the new defaults file apparently doesn’t have the innodb_data_file_path entry in it (I am 100% certain that it does, I am looking at it right now!!).

The file permissions on the new file are 644. I have no idea why this is happening. I suspect this may be related to the fact the backup is on a CIFS share, but need to be sure this is the case, however we don’t have any spare disks to use to put the backup on to before restoring. See output from innobackupex command below:

innobackupex --defaults-file ./backup-my.cnf --apply-log --export /backups/20150723

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

Get the latest version of Percona XtraBackup, documentation, and help resources:
[url]Percona XtraBackup - MySQL Database Backup Software

150727 11:59:19 innobackupex: Starting the apply-log operation

IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints “completed OK!”.

Warning: World-writable config file ‘/mnt/backup/mysql/20150723/backup-my.cnf’ is ignored
innobackupex: got a fatal error with the following stacktrace: at /usr/bin/innobackupex line 4545
main::get_option(‘innodb_data_file_path’) called at /usr/bin/innobackupex line 2631
main::apply_log() called at /usr/bin/innobackupex line 1578
innobackupex: Error: no ‘innodb_data_file_path’ option in group ‘mysqld’ in server configuration file ‘/root/backup-my.cnf’ at /usr/bin/innobackupex line 4545.

2

Can you run it with innobackupex --apply-log /backupdir only without --defaults-file=, let us know how it goes.

3

Hi,

Yes I did, but it didn’t work. The issue was down to the fact the backup was on a CIFS share. When I took the backup off to a local disk and altered the permissions, it worked fine. However, now when I try to restore the table it complains with the following:

error -1 from storage engine

There is enough space on the server for the table to sit (over 100GB free on the local disk), and the --apply-log --export command worked fine. No errors reported. I am using MariaDB 5.5, so no need for the .cfg file. Any ideas where to go next? The error log shows me this:

150730 12:11:17 InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file ‘./t2m_client_71/RECOVERY.ibd’!
150730 12:11:17 InnoDB: Error: cannot reset lsn’s in table t2m_client_71.RECOVERY
InnoDB: in ALTER TABLE … IMPORT TABLESPACE
150730 12:11:34 InnoDB: Error: tablespace id and flags in file ‘./t2m_client_71/RECOVERY.ibd’ are 15300 and 0, but in the InnoDB
InnoDB: data dictionary they are 16270 and 0.

The ibdata file was restored from the same backup as the table, so I’m not sure why it would come up with this error…anyone got any ideas what to do next?

Regards,

Tom