MySQL Bugs: #31309: Master binary log for replication fails with event too small message

Bug #31309	Master binary log for replication fails with event too small message
Submitted:	1 Oct 2007 8:36	Modified:	15 Jan 2008 10:36
Reporter:	Leif Koch	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S1 (Critical)
Version:	5.0.45	OS:	Linux (Debian Etch 2.6.22-2-amd64)
Assigned to:		CPU Architecture:	Any

Description:
Replication only works for up to a few hours (at most we managed 2 so far), then the MySQL slave SQL thread stops due to an apparently corrupted master binlog with the message:

mysqld[3316]: 070926 8:16:26 [ERROR] Slave: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 0

Running mysqlbinlog on the master's binary log then ends with this message:

ERROR: Error in Log_event::read_log_event(): 'Event too small', data_len: 0, event_type: 0
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

This occurs always when starting repliction.

We have tried this for a couple of months now with various kernels, switched from stable to unstable, and various libc6 and mysql-server-5.0 releases. We have been using 2.6.18 and 2.6.22-2-amd64 with 4 gb RAM on Intel Core2 Duo 6600 cpus (2.4 ghz).

I'm not sure whether this is a Debian- or MySQL-related bug, though one of the Debian maintainers has told me this is not Debian-specific.

If there is something we could do to further investigate this, please let me know.

How to repeat:
We currently have no specific instructions on how to repeat this problem. The queries in the master binary log differ each time before the empty sequence appears.

I am periodically experiencing the same issue on 5.1.20-beta on Ubuntu 6.06 running 2.6.15-28-amd64

I use the exact same type of OS, CPU version of MySQL and have the exact same problem. No matter what I change in the configurationfile I get these dreaded (exactly the same) errors. Effectively making it impossible to use replication. I try to replicate from a 32-bit master (using the same version of mysql).

(by the way with 'exactly the same' I meant the same as Leifs setup)

I've gone into some extent to try and produce a workaraound. Only resulting in a few things you don't have to try, because they don't work. Though, it may be interesting.

I've tried to to run 32-bit mysql with IA-32 libs, and in a debootstrapped chroot environment, both running on the amd64 kernel, giving the same errors. When I load the same dump into a mysql-server that runs on a 32bit kernel and I start replication all goes as it should. It thus seems that the problem is not specificly in the 64bit version of mysql. 

I could provide MySQL development with a amd64 server with this kind of CPUs (where this problem only seems to occur) for testing purposes. This machine is not going to be doing anything until this issue is resolved anyway, so please feel free to contact me for this.

Hello MySQL team, 
just wondering whether anyone is already looking into this? Or can you give an estimate when someone might be able to work on it?
Thanks!

We have solved this issue by adding sync_binlog=1 to our master configuration. I've therefore switched the status to "Not a Bug".