innodb_data_file_path is handled by innobackupex incorrectly

[Sergei Glushchenko]

Test case:

###############################################################################
# This testcase demonstrates incorrect handling of innodb-data-file-path by
# innobackupex script
###############################################################################

. inc/common.sh

cheaty_path=test_table.MYD:10M:autoextend

start_server --innodb-data-file-path=$cheaty_path

echo "innodb-data-file-path=$cheaty_path" >>$topdir/my.cnf

${MYSQL} ${MYSQL_ARGS} test <<EOF
create table test_table (a int) engine=MyISAM;
insert into test_table values (100);
EOF

backup_dir=$topdir/backup
innobackupex --no-timestamp $backup_dir

vlog "Backup created in directory $backup_dir"

stop_server
rm -rf $mysql_datadir/*
vlog "Data destroyed"

innobackupex --copy-back $backup_dir

start_server

# Following will fail if bug is present
${MYSQL} ${MYSQL_ARGS} test <<EOF
select * from test_table;
EOF

Is failing with message:
ERROR 29 (HY000) at line 1: File './test/test_table.MYD' not found (Errcode: 2)

[Alexey Kopytov (akopytov)]

What's exactly is the condition that triggers this bug? Is it that the system tablespace name must end with '.MYD'?

[Sergei Glushchenko (sergei.glushchenko)]

The copy_back routine construct regexp to skip files. It looks like ^(pattern1|...|patternN)$. Among the others one of the patterns will look like 'test_table.MYD'. This patent then is used to filter out the output of File::find inside the callback. Variables which passed inside callback are:

$File::Find::dir = /some/path/
$_ = foo.ext
$File::Find::name = /some/path/foo.ext

Matching is performed against $_, which means that files which are named same as system system tablespace will not be restored from backup.

[Alexey Kopytov (akopytov)]

Thanks.

[Shahriyar Rzayev (rzayev-sehriyar)]

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