Bug #53527 Binary log may get corrupted due to a crash while writing a large transaction
Submitted: 10 May 2010 7:23 Modified: 30 Mar 2011 10:04
Reporter: Alfranio Tavares Correia Junior Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.0, 5.1, 5.5 OS:Any
Assigned to: Daogang Qu CPU Architecture:Any
Tags: binlog, crash, recovery

[10 May 2010 7:23] Alfranio Tavares Correia Junior 
Description:
MySQL writes transactions to the binary log in batches. In case of server crash
during those batch operations, an incomplete transaction may be present in the binary log.

This happens because the unit of atomicity in I/O operations is usually a sector
(i.e 512 bytes) which means that transaction’s data may be partially written due
to a crash, e.g. power failure.

How to repeat:
Check the code.

Suggested fix:
To circumvent this problem, we could use an anchor area by reserving a fixed
space (a sector, i.e. 512 bytes) in the beginning of the binary log to store its
size. 

So, after writing the transaction to the binary log, the reserved space is updated with the new size and during recovery, the file is truncated according to the stored information.

The anchor area could also be stored in the binary log index file. However,
note that the index file is not crash-safe either. See BUG#52620.
[25 Jan 2011 12:20] Luis Soares 
WL#5493 will fix this.
[30 Mar 2011 10:04] Jon Stephens 
Fixed by WL#5493.
[31 Aug 2011 14:53] Mark Callaghan 
Please update this with a description of the version in which this has been fixed.

I am amused that this is marked as a feature request. Crash-safety is a requirement, not a feature, for something claiming to support OLTP
[2 Sep 2011 11:29] Luis Soares 
This bug fix was included in 5.6 DM release back in April this year.