MySQL Bugs: #57122: mysqlbackup (innobackup C port) unlocks tables too early

Bug #57122	mysqlbackup (innobackup C port) unlocks tables too early
Submitted:	30 Sep 2010 7:46	Modified:	2 Dec 2010 0:08
Reporter:	Victor Kirkebo	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Backup	Severity:	S3 (Non-critical)
Version:	3.5	OS:	Any
Assigned to:	Satya B	CPU Architecture:	Any

Description:
mysqlbackup which is the new C version of the innobacup perl script is releasing a global read lock too early.

innobackup (perl script):
=========================
* ibbackup --suspend-at-end …; (this starts the backup of innodb tables)
* when the script (innobackup) notices the file ibbackup_suspended appears:
     1. FLUSH TABLES WITH READ LOCK;
     2. copy all .frm files and MyISAM tables from database directories to a  backup location;
     3. resume the ibbackup run by deleting the file ibbackup_suspended;
     4. UNLOCK TABLES;

mysqlbackup (c version):
========================
* ibbackup --suspend-at-end …; (this starts the backup of innodb tables)
* when the script (innobackup) notices the file ibbackup_suspended appears:
     1. FLUSH TABLES WITH READ LOCK;
     2. copy all .frm files and MyISAM tables from database directories to a  backup location;
     3. UNLOCK TABLES;
     4. resume the ibbackup run by deleting the file ibbackup_suspended;

The consequence of calling "UNLOCK TABLES" before resuming the ibbackup application is that non-innodb tables (MyISAM e.g.) can be updated while ibbackup is finishing the backup of innodb tables. These updates will then be missing in the backup image.

How to repeat:
Please read the source code of innodb perl script and mysqlbackup c code.

Thank you for the report.

Verified as described.

Hi Victor,

After reducing number of threads, I was able to reproduce. The test duration is also very less.

Thanks!

Approved. Please see email for a change request.

The code changes for the patch looks fine and OK to push.