tries to create temporary tables in relative ./tmp directory

Reported by Brad Fino on 2009-07-22
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup
Medium
Unassigned

Bug Description

Looks like it's trying to create temporary files in a relative ./tmp directory instead of absolute /tmp.

InnoDB: Doing recovery: scanned up to log sequence number 861 2660283392 (13 %)
InnoDB: Doing recovery: scanned up to log sequence number 861 2665526272 (14 %)
InnoDB: Doing recovery: scanned up to log sequence number 861 2670769152 (14 %)
InnoDB: Doing recovery: scanned up to log sequence number 861 2676012032 (15 %)
090721 23:03:14 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: File name .//tmp/#sql4920_2_c.ibd
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.

In this case, I ran innobackupex-1.5.1 --apply-log from /data/mysql. If I mkdir /data/mysql/tmp then it goes through recovery no problem. Can this be fixed to create temporary files in /tmp instead of ./tmp ?

Changed in percona-xtrabackup:
assignee: nobody → Yasufumi Kinoshita (yasufumi-kinoshita)
importance: Undecided → Medium

This behavior is related to the bugs of MySQL which are still not fixed....

e.g.
http://bugs.mysql.com/bug.php?id=41609
http://bugs.mysql.com/bug.php?id=45638
http://bugs.mysql.com/bug.php?id=45976

Basically, innodb temporary table and recovery may be not so compatible for now.
XtraBackup is depend on recovery function of built-in InnoDB and the bugs affect also to XtraBackup....

I think InnoDB should not log operation about temporary tables....
And should remove all temporary tables when recovery....
So, it may be from fundamental bug of InnoDB.....

Anyway, xtrabackup must continue operation by skipping the error.
(the ibd file is for temporary table, so it is not needed to recover... Nobody can use the table...)

I will fix to skip the error for now as first-aid.

Even by the first-aid we can backup, the garbage entry at the dictionary will be remained...
I don't recommend to use innodb temporary tables for now, until the above bugs are fixed.

The first-aid is added. xtrabackup will continue the operation.

http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/89

Changed in percona-xtrabackup:
status: New → Fix Committed
Changed in percona-xtrabackup:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.