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

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.

WL#5493 will fix this.

Fixed by WL#5493.

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

This bug fix was included in 5.6 DM release back in April this year.

Page generated in 0.042 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.