Restoring database leads to a couple of corrupted ibd


I’m working on improving the way we do backup of our mysql server using xtrabackup, which includes testing restoration scenario.

the restoration I just did gave me an error about 2 ibd files (among 200 tables) which are reported this way

2021-03-03T09:25:18.724912Z 28 [ERROR] InnoDB: Failed to find tablespace for table `db_name`.`table_name` in the cache. Attempting to load the tablespace with space id 50561
2021-03-03T09:25:18.724992Z 28 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace other_db/table_name at filepath: ./other_db/table_name.ibd uses space ID: 50563. Cannot open filepath: ./db_name/table_name.ibd which uses the same space ID.
2021-03-03T09:25:18.724999Z 28 [ERROR] InnoDB: Operating system error number 2 in a file operation.
2021-03-03T09:25:18.725002Z 28 [ERROR] InnoDB: The error means the system cannot find the path specified.
2021-03-03T09:25:18.725005Z 28 [ERROR] InnoDB: Could not find a valid tablespace file for `db_name/table_name`. Please refer to for how to resolve the issue.
2021-03-03T09:25:18.725027Z 28 [Warning] InnoDB: Cannot calculate statistics for table `db_name`.`table_name` because the .ibd file is missing. Please refer to for how to resolve the issue.

The specified idb files are on the disk and not-zero sized.
This seems to have a big impact on the server as I can see since CPU spike and such exception message

Thread pointer: 0x7f24e4000d40
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f3c5c285e50 thread_stack 0x40000

I’m backing up this way

xtrabackup --compress --backup --stream=xbstream --parallel 10 --encrypt=AES256 --encrypt-threads=4 --encrypt-key="xxx" --databases="db_name" | xbcloud put db_name_full_2021030201 --parallel 10 --swift-container="database_backup_db_name_2021030201"

and restoring this way
(I use Restoring Individual Tables as reference as I assumed restoring a database is just restoring a list of tables)

# sh: xbcloud get --parallel=10 --swift-container=database_backup_db_name_2021030301 db_name_full_2021030301 --parallel=10 | xbstream -xv -C /data/backups/full_db_db_name --parallel=10
# sh: xtrabackup --decompress --decrypt=AES256 --encrypt-key="xxxx" --target-dir=/data/backups/full_db_db_name --remove-original
# sh: xtrabackup --prepare --target-dir=/data/backups/full_db_db_name --use-memory 2G --export
mysql> SELECT CONCAT( 'ALTER TABLE ', a.TABLE_SCHEMA, '.', a.TABLE_NAME, ' DISCARD TABLESPACE;' ) FROM information_schema.tables a WHERE a.TABLE_SCHEMA='db_name';
# sh: cp -a full_db_db_name/db_name/* /var/lib/mysql/db_name/
# sh: chown mysql:mysql -R  /var/lib/mysql/db_name/
mysql> SELECT CONCAT( 'ALTER TABLE ', a.TABLE_SCHEMA, '.', a.TABLE_NAME, ' IMPORT TABLESPACE;' ) FROM information_schema.tables a WHERE a.TABLE_SCHEMA='db_name';

I’m using a different server (and also different version) for backup and restore.

Software stack

  • percona-xtrabackup: 2.4.21
  • mysql source server: 5.6.43
  • mysql destination server: 5.7.33

Is there something I’m doing wrong in the backup or restore process ?


1 Like

I am not sure this will work if source and target are different versions. Can you try using the same version?
Also do ALL tables exist on the target server? if not you need to pre-create them before dropping the table spaces.

1 Like

having the same version for source and target works indeed, so I assume having a different version does not work.

is it possible to create the tables from thefrm files stored in the backup ? is there a tool for that ?

1 Like

You might want to have a look at How to recover table structure from .frm files with MySQL Utilities