MySQL Bugs: #70895: Replication failure for data from version 5.6 to 5.5

Bug #70895	Replication failure for data from version 5.6 to 5.5
Submitted:	13 Nov 2013 11:47	Modified:	14 Nov 2013 17:05
Reporter:	Vivek Viswanathan	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.6.14	OS:	Linux (RHEL)
Assigned to:		CPU Architecture:	Any
Tags:	ERROR: Error in Log_event::read_log_event(): 'Sanity check failed'

Description:
In a replicated environment, on upgrading the slave from version 5.5 to 5.6, the data replicated from version 5.5 to 5.6 works fine but I get the following error when replicating data from version 5.6 to 5.5:
"
Relay log read failure: 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.
"

I can read the master log without any problems on the master.
On trying to read the relay log on the slave, I see the following error:
"
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 239, event_type: 31
"

How to repeat:
Setup a 2 server master-master replicated environment on version 5.5.28.

Upgrade one of the them to version 5.6.14.
Replication from version 5.5 to 5.6 works fins but seems to be failing when data goes from 5.6 to 5.5.

The following changes were made in the master environment (version 5.6):
binlog_checksum=NONE
If this is not set, then the slave thread does not startup on version 5.5
If this is set, then the replication thread starts up but if any DDl/DML is executed in the master environment then the replication errors as above on the slave environment (version 5.5).

As far as I know, replication is not guaranteed to work if slave is *lesser* version than master.

Peter
(not a MySQL/Oracle person)

Many Thanks for your update Peter!

If this is not treated as an issue/bug, then the minimum I would like to know is what has changed in version 5.6 which is not allowing the replicated SQL statements to be executed on version 5.5.

Thanks and Regards,
Vivek.

Let the MySQL supporters details this.  It is probably also documented.

But to me it is logical that an old version cannot know about changes to the binlog of a newer version. So my best guess is that the reason 5.6 binlogs some details otherwise than 5.5 does. So much otherwise that 5.5 does not understand how to use a 5.6 binlog.

In general I think you cannot expect old versions of any program to read files generated by newer versions.  New versions can be made compatible with files generated by old versions (because when a new version is released, details of older versions are known, but when an old version was released, details of newer versions were not known - and could not possibly be).

Also see http://bugs.mysql.com/bug.php?id=70879

Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Replication from newer server to older one is not supported.