The politically correct answer would be that you cannot perform MySQL Replication from a newer Master to an older Slave. You proven the politically correct answer to be wrong. Notwithstanding, the correct answer is you shouldn't do it, at least not for very long. Consequently, I have a very strong warning for you: It can be very unstable and you should upgrade ASAP. Why ?
The book Understanding MySQL Internals (click to download PDF)
has a section on binary log events (pages 223-227). Those events have unique codes that are being interpreted as follows:
- codes get interpreted by mysqlbinlog when extracting and displaying SQL commands
- MySQL Replication
- IO Thread interprets events and checks for validity before storing the events in the binlog
- SQL Threads interprets events from relay log and executes the commands
The error message you are getting comes from that validity check by the Replication Threads.
What's funny about this is that the book I quoted was made in April 2007. There have been more binlog events added to MySQL since that book's publication. Thus, there will be occasions when a Slave cannot interpret a binlog event and just consider the relay log corrupt. (It's like a conversation between two people from England and Brooklyn USA, or Brazil and Portugal, or Spain and Puerto Rico). The slight shift in vocabulary between binlogs from two different versions of MySQL is just being misconstrued as unintelligible between them.
About a month ago, a client was using 5.5.30 Master and 5.6.21 slave (On the path of migration to MySQL 5.6.21 (Master and All Slaves)). Although this replication setup works at present, there have been occasions when the Slave would break because it could not unpack a binlog event from an older Master. I learned of this phenomenon from my boss when he showed me the error in the error log. It had a rather cryptic error message (when MySQL Replication would either start or rotate relay logs) with the word Unpack (You should do grep -i unpack error.log and see if this is the case for you). If this is possible (as I have seen happen and have done maintenances to correct), then the reverse is more likely (the reverse being a new Master and an older Slave).
For the sake of your sanity and your database topology, please upgrade.