Binlog corruption when tmpdir gets full
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
||||
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.5 |
Won't Fix
|
Undecided
|
Unassigned | |||
5.6 |
Triaged
|
High
|
Unassigned | |||
5.7 |
Invalid
|
High
|
Unassigned | |||
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC | Status tracked in 5.6 | |||||
5.6 |
Confirmed
|
Undecided
|
Unassigned | |||
5.7 |
Invalid
|
Undecided
|
Unassigned |
Bug Description
In a situation where disk partition used for tmpdir has little free space, and large enough write transaction is executed, which does not fit in binlog_cache_size, an individual write fails with error, but actual binary log gets corrupted, causing the slave to fail.
Reproduced for InnoDB tables with compound primary key, with standard replication as well as for PXC.
Example error messages when tmpdir gets full (ML* of MY* files gets created, apparently depending on whether total transaction file can't be increased (ML) or individual update query (MY)):
master [localhost] {msandbox} (test) > update test1 set a=a+1,b=b+1,c=c+2 limit 110000;
ERROR 3 (HY000): Error writing file '/home/
master [localhost] {msandbox} (test) > update test1 set a=a+1,b=b+1,c=c+2 limit 210000;
ERROR 3 (HY000): Error writing file '/home/
Example error on the slave side:
Example error on PXC slave node:
2017-07-07 18:50:39 8665 [ERROR] Error in Log_event:
2017-07-07 18:50:39 8665 [ERROR] WSREP: applier could not read binlog event, seqno: 378308, len: 2680586
2017-07-07 18:50:47 8665 [Warning] WSREP: Failed to apply app buffer: seqno: 378308, status: 1
at galera/
Retrying 2th time
Example output from mysqlbinlog tool:
ERROR: Error in Log_event:
ERROR: Could not read entry at offset 7233086: Error in log format or read error.
WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set. This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement. The event(s) from the partial statement have not been written to output.
Test case to be found in upstream bug report: https:/
tags: | added: upstream |
Why 5.7 has been set to Invalid? https:/ /bugs.mysql. com/bug. php?id= 72457 says "[8 May 20:13] Jay Edgar
I was able to reproduce this on both 5.6.35 and 5.7.18."