Comment 4 for bug 1398994

Revision history for this message
Andrew Garner (muzazzi) wrote :

I was able to create a simple reproducible set of steps to recreate this issue. This seems to be DDL related rather than DML related - I can't reproduce this with any normal DML workload.

I created a small sandbox - for the test case using MySQL 5.6.22 from a binary tarball acquired from the mysql.com cdn.

I created two databases:

mysql[sandbox]> SELECT @@version, @@version_comment;
+------------+------------------------------+
| @@version | @@version_comment |
+------------+------------------------------+
| 5.6.22-log | MySQL Community Server (GPL) |
+------------+------------------------------+
1 row in set (0.00 sec)

mysql[sandbox]> create database include00;
Query OK, 1 row affected (0.00 sec)

mysql[sandbox]> create database exclude00;
Query OK, 1 row affected (0.00 sec)

I created a simple table structure in the include00 database:

mysql[sandbox]> use include00
Database changed
mysql[sandbox]> create table table00 (id bigint unsigned primary key auto_increment, data varchar(40)) engine=innodb character set = utf8;
Query OK, 0 rows affected (0.03 sec)

I populated this with data until the table was a few hundred MB in size - large enough that the copy would pause momentarily while copying this table so I could ensure the DDL operation on a table in an excluded database completes before the backup ends.

I create an empty table in the exclude00 database.

mysql[sandbox]> create table excluded_table00 (id int) engine=innodb;
Query OK, 0 rows affected (0.03 sec)

I start xtrabackup:

# innobackupex --defaults-file=$PWD/my.sandbox.cnf --databases=include00 /backups/

After xtrabackup starts copying tablespace I issue a DDL command:

mysql[sandbox]> truncate table excluded_table00;
Query OK, 0 rows affected (0.03 sec)

Xtrabackup finishes and I see:

xtrabackup: Transaction log of lsn (1025116390) to (1025124616) was copied.
innobackupex: Backup created in directory '/backups/2014-12-29_18-43-43'

The contents of /backups/2014-12-29_18-43-43 are as expected (prior to prepare):

# tree -a /backups/2014-12-29_18-43-43
/backups/2014-12-29_18-43-43
├── backup-my.cnf
├── ibdata1
├── include00
│   ├── db.opt
│   ├── table00.frm
│   └── table00.ibd
├── xtrabackup_checkpoints
├── xtrabackup_info
└── xtrabackup_logfile

I prepare the backup:

# innobackupex --apply-log /backups/2014-12-29_18-43-43
...
141229 18:46:00 innobackupex: completed OK!

And the post-prepare contents are:

# tree -a /backups/2014-12-29_18-43-43
/backups/2014-12-29_18-43-43
├── backup-my.cnf
├── exclude00
│   └── excluded_table00.ibd
├── ibdata1
├── ib_logfile0
├── ib_logfile1
├── include00
│   ├── db.opt
│   ├── table00.frm
│   └── table00.ibd
├── xtrabackup_checkpoints
├── xtrabackup_info
└── xtrabackup_logfile

2 directories, 11 files

The exclude00/excluded_table00.ibd has appeared which is not expected. I have attached the innobackupex --apply-log output.