Comment 3 for bug 955057

Hi Alex,

The warning always appears in the slave error log when you have a master that does not recognize the variable; it does not normally break replication. I have 5.1.55 -> 5.3.5 replication setup, it does indeed produce the warning on startup, but continues working as expected.

The query that you are talking about
SET @master_binlog_checksum= @@global.binlog_checksum
is generic, it is executed regardless of the variable value on slave. This way slave finds out whether master is capable of writing binlog checksums, and it helps the dump thread initialize properly.

The fact that it happened the same second as the error that broke replication is irrelevant because, as I understand, it was the moment when your slave threads were initializing. I suppose right before the warning you had the record similar to
[Note] Slave I/O thread: connected to master .... ,replication started in log

That is, the IO thread connected (wrote the note), went through the handshake (wrote the warning), started reading binlog events and found a bad one, which caused the error.

So, while without looking at the logs we cannot completely rule out any relation between the warning and the packet error, it seems rather unlikely. At the same time, regardless binlog checksums, the problem 'log event entry exceeded max_allowed_packet' has a long history in MySQL:
http://bugs.mysql.com/bug.php?id=8215 -- bug of 2005
http://www.linuxquestions.org/questions/linux-newbie-8/got-fatal-error-1236-log-event-entry-exceeded-max_allowed_packet-mysql-replication-839336/ -- message of 2011
.. and plenty in between.
Due to the lack of details and evidence, more often than not real causes of the failure remained suspected but not proved (disk failures, errors in binlog writing, external libraries, to name a few). So, we really need the logs to be able to give investigation a try.

Thank you.