xtrabackup handling of space id conflicts

[Jervin R]

Description:

If by any means, a stray tablespace made it through a datadir being backed up which conflicts with an existing space id in the data dictionary the backup will succeed but during prepare can lead to losing the actual table.

How to repeat:

Using mysqlsandbox, create a table t and stow away the ibd then destroy the sandbox. Create the same sandbox version and same table, then copy the first ibd under a different name i.e. space_id. Take a backup and you will get the error below:

xtrabackup: Generating a list of tablespaces
InnoDB: Attempted to open a previously opened tablespace. Previous tablespace test/space_id uses space ID: 10 at filepath: ./test/space_id.ibd. Cannot open tablespace test/t which uses space ID: 10 at filepath: ./test/t.ibd
[01] Copying ./ibdata1 to /opt/msb/msb_5_5_430/2015-07-16_23-57-48/ibdata1
[01] ...done
[01] Copying ./test/space_id.ibd to /opt/msb/msb_5_5_430/2015-07-16_23-57-48/test/space_id.ibd
[01] ...done
>> log scanned up to (1601607)
xtrabackup: Creating suspend file '/opt/msb/msb_5_5_430/2015-07-16_23-57-48/xtrabackup_suspended_2' with pid '28074'

Notice that instead of table t, space_id.ibd was copied which means the intended table was lost in the backup.

[Valerii Kravchuk (valerii-kravchuk)]

Code review also shows that error like this: "InnoDB: Attempted to open a previously opened tablespace..." is explicitly ignored in backup mode. Check the code of fil_load_single_table_tablespace().

[Valerii Kravchuk (valerii-kravchuk)]

The code in storage/innobase/fil/fil0fil.cc is written so to ignore that error of duplicate space id in backup mode:

4280 def.file = os_file_create_simple_no_error_handling(
4281 innodb_file_data_key, def.filepath, OS_FILE_OPEN,
4282 OS_FILE_READ_WRITE, &def.success);
4283
4284 /* Read the first page of the remote tablespace */
4285 if (def.success) {
4286 fil_validate_single_table_tablespace(tablename, &def);
4287 if (!def.success) {
4288 os_file_close(def.file);
4289
4290 if (srv_backup_mode) {
4291
4292 /* Ignore files that have uninitialized spa ce
4293 IDs on the backup stage. This means that a
4294 tablespace has just been created and we wil l
4295 replay the corresponding log records on
4296 prepare. */
4297
4298 goto func_exit_after_close;
4299 }
4300 }

[Sergei Glushchenko (sergei.glushchenko)]

https://github.com/percona/percona-xtrabackup/pull/86

[Shahriyar Rzayev (rzayev-sehriyar)]

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