multiple instances of innobackupex can conflict with each other

[Josh]

I had a situation where I accidentally ran two instances of innobackupex (call them "Thing 1" and "Thing 2") with the same --tmpdir. Due to differences in the storage media they were writing to, Thing 2's xtrabackup proceeded much faster than Thing 1's. When Thing 2's xtrabackup finished, it created $suspend_file. Thing 1 saw the $suspend_file, said "THIS IS MY MOMENT!", and issued a FLUSH TABLES WITH READ LOCK [1]. Thing 2 also saw $suspend_file, tried to write to XTRABACKUP_PID, and got a permission denied error [2].

At this point, Thing 1 executed wait_for_ibbackup_log_copy_finish, still holding its FLUSH TABLES WITH READ LOCK (as designed) [3]. It stayed this way until an administrator killed Thing 1's xtrabackup process.

I believe this could be fixed by having innobackupex create and flock a file called 'innobackupex_lock' within tmpdir when it starts up. This would prevent hapless administrators from accidentally using innobackupex twice with the same tmpdir.

[1] http://paste.ubuntu.com/9696679/
[2] http://paste.ubuntu.com/9696664/
[3] http://paste.ubuntu.com/9696697/

[Josh (hashbrowncipher)]

Probably a better solution than the lock file would be to namespace the temporary directory. For this solution, innobackupex would use mktemp to create a temporary directory within the tmpdir, and there would be no possibility of conflicts between separate instances of innobackupex.