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 ?
This behavior is related to the bugs of MySQL which are still not fixed....
e.g.
http://
http://
http://
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.