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

[28 Oct 2010 11:37] Victor Kirkebo
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.
[25 Nov 2010 14:07] Victor Kirkebo
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'.
[6 Dec 2010 12:07] Thava Alagu
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.