MySQL Bugs: #57803: Accuracy of reported binlog position when doing backup

Bug #57803	Accuracy of reported binlog position when doing backup
Submitted:	28 Oct 2010 11:37	Modified:	6 Dec 2010 12:07
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:	Thava Alagu	CPU Architecture:	Any

Description:
I would like someone to look into the accuracy of the binlog position as reported by mysqlbackup and ibbackup.
Sometimes when running a full backup followed by --apply-log two different values are reported - one value by mysqlbackup (doing full backup) and another by ibbackup (when applying log). When this happens there is also the additional issue that the backup image may actually contain updates which in the binlog have a position after both the binlog positions reported by mysqlbackup and ibbackup.

How to repeat:
I will provide a pointer to output from a sample test run where this happened.
This does not happen very often. I have not yet been able to make a test case that can easily reproduce this.

I have filed bug#58489 that I believe is the cause of the problem seen with the reported binlog position when doing backup. I have only seen this happen with 5.5.7-rc. If bug#58489 gets verified and turns out to be the cause of the backup problem this bug report should be closed as 'Not a bug'.

The problem happens only with mysql server 5.5.8 where the FLUSH TABLES WITH READ LOCK behaviour changed to do implicit commit. Hence FTWRL commits and then obtains the read lock, and there could be possibly other transactions done within that window. This confuses MEB. As such there is no plan to change MEB to fix this as server implementation is expected to undo the implicit commit. Hence I am closing the bug.