innobackupex doesn't copy xtrabackup_logfile if 'UNLOCK TABLES' times out at end of script

Is this still reproducible in current xtrabackup? there have been a lot of bug fixes since this bug was filed. Please try to reproduce with a more recent release.

thanks for your report, and sorry it has stagnated for so long.

------
111026 02:37:53 innobackupex: Finished backing
up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt
files

innobackupex: Resuming ibbackup

xtrabackup: The latest check point (for incremental): '191499091912'
log scanned up to (191499360626)
xtrabackup: Stopping log copying thread.......
xtrabackup: Transaction log of lsn (191487786897) to (191499360626) was
copied.
innobackupex: Error: mysql child process has died: ERROR 2006 (HY000) at
line 13: MySQL server has gone away
while waiting for reply to MySQL request: 'UNLOCK TABLES;'
at /usr/bin/innobackupex line 336.
------

===> so wait_timeout reached before the copying of the FRM files was done.

===> There is some mechanism that checks if the connection should be pinged, but it's not really intelligent:
#
# mysql_keep_alive subroutine tries to keep connection to the mysqld database
# server alive by sending a dummy query when the connection has been idle
# for the specified time.
#
sub mysql_keep_alive {
    if ((time() - $mysql_last_access_time) > $mysql_keep_alive_timeout) {
        # too long idle, send a dummy query
        mysql_check();
    }
}

===> default setting is not that good:
# time in seconds after which a dummy query is sent to mysql server
# in order to keep the database connection alive
my $mysql_keep_alive_timeout = 1800;

===> In this case, wait_timeout was set to 100, which is much lower than that default value.

===> HOWEVER, changing $mysql_keep_alive_timeout is not enough because it does run mysql_keep_alive every time a file has been copied so when the file is big and will take longer than 100 seconds, it will fail

===> a (dirty) way that it can be fixed is by applying the patch below and expecting a file not to take longer than 57600 seconds

We should probably ignore the result of UNLOCK TABLES as it failing/timing out really isn't anything that affects us (tables would be unlocked when we disconnect from server anyway)

It looks like the real problem was that the client connection timed out before innobackupex issued UNLOCK TABLES, but rather when copying non-InnoDB diles. It's just that the error message is misleading in such a case.

So it is essentially a duplicate of bug #408803 and will be addressed by the same patch.