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" (ISBN 0-596-00957-7)
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 stores the events in the binlog
- SQL Threads interprets and validates 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 six(6) weeks 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) Here is a snippet from that error log:
Thread pointer: 0x7ff048000990
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
stack_bottom = 7ff14cb347e0 thread_stack 0x40000
Please note these four lines
In my particular case, the Slave would crash trying to interpret the binlog event.
What would happen is the following:
- STEP 01 : Slave would crash on the unrecognized event
- STEP 02 : mysqld_safe would restart mysqld
- STEP 03 : mysqld would try to start replication again (skip-slave-start not configured)
- STEP 04 : Go back to STEP 01
To correct this madness, I had to do the following:
kill -9 on the mysqld_safe process
service mysql start --skip-slave-start
CHANGE MASTER TO the next available position
From there, replication was off and running. This has happened to my boss once and to me once. Of course, I reloaded the data from the Master in full to get the Slave sync'd (Good thing the database was less than 100MB).
If this crazy scenario was possible from a MySQL 5.5.30 Master to MySQL 5.6.21 Slave, (as I have shown happen and two maintenance cycles to correct), then the reverse is far more likely (the reverse being a new Master and an older Slave).
For the sake of your sanity and your database topology, please upgrade.