I upgraded to XtraBackup 2.0.2 last week, but we immediately started having problems when the backups were completing. By swapping back to 1.6.4 and then to 2.0.2 again over a couple of nights, I verified that this is XtraBackup.
It seems that in the last couple of minutes of our backup - after MyISAM files have been unlocked but before the completion of the backup, our entire server becomes blocked. Other connections are no longer able to perform queries. The XtraBackup log does not indicate any problems. Here is a short excerpt from the end of the log:
120910 05:26:10 innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt filesinnobackupex: Resuming ibbackupxtrabackup: The latest check point (for incremental): '9877664875121’xtrabackup: Stopping log copying thread…>> log scanned up to (9878545395759)xtrabackup: Streaming transaction log from a temporary file…xtrabackup: Done.xtrabackup: Transaction log of lsn (9873735831255) to (9878545395759) was copied.120910 05:29:25 innobackupex: All tables unlocked120910 05:29:25 innobackupex: Connection to database server closedinnobackupex: Backup created in directory 'altered for privacy’innobackupex: MySQL binlog position: filename ‘mysql-bin.002466’, position 386201097innobackupex: You must use -i (–ignore-zeros) option for extraction of the tar stream.120910 05:29:25 innobackupex: completed OK!
On this day, our systems began reporting errors at 05:26:26 and got back to normal around 05:29:51. This seems consistent with the portion of this log that indicates “Streaming transaction log from a temporary file.” Is there a way to avoid this problem? Is this a known bug? For now, I’m reverting all my servers to XtraBackup 1.6.4. It does not exhibit this behavior.
In case these details are helpful, we’re running MySQL 5.5.23 on CentOS 6. Our backup takes about 1.5 hours to complete as a streaming tar archive.
Thanks,
Dave