truncate table causes backup to fail

[Charl]

While using InnoDB storage engine with "innodb_file_per_table" enabled performing a 'TRUNCATE TABLE <<table_name>>' sql command while performing a backup (full or incremental) causes the backup to fail.

The last part of the log contains this message:

>> log scanned up to (223972107711)
>> log scanned up to (223972107711)
InnoDB: Error: tablespace id is 80254 in the data dictionary
InnoDB: but in file ./testdb/abc_tablename.ibd it is 80838!
110815 9:50:31 InnoDB: Assertion failure in thread 140070147725072 in file /var/lib/buildbot/slaves/percona-server-51-12/DEB_Ubuntu_Lucid_amd64/work/xtrabackup-1.6.2/Percona-S$
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex line 336.

According to the MySQL manual (http://dev.mysql.md/doc/refman/5.5/en/truncate-table.html):
"if there are no FOREIGN KEY constraints, InnoDB performs fast truncation by dropping the original table and creating an empty one with the same definition"

I am running xtrabackup_55 version 1.6.2 with MySQL 5.5.10 on Ubuntu Linux 10.04 64-bit.

[Charl (charlretief)]

This bug is related to bug #722638.

[Alexey Kopytov (akopytov)]

It is actually a duplicate of bug #722638, since TRUNCATE = DROP + CREATE as mentioned in the quoted snippet from the manual.