CODEWITHSUNDEEP
mysqldatabase-replicationmysql-5.6mysql-5.1
user2174646
user2174646

Reputation: 135

Mysql 5.6 to 5.1 replication

I know that mysql does not support this. But according to http://dev.mysql.com/doc/refman/5.6/en/replication-compatibility.html and also https://serverfault.com/questions/262936/is-replication-from-mysql-5-5-master-to-a-5-1-slave-possible it is possible.

I am running into the issue:

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.

the binlogs are not corrupt but the relay log is corrupt even if I reset the replication. There is no corruption on the master. It is only on the slave that there is corruption.

it appears to only happen on utf8 tables. To be more specific there is no corruption in the relay log until after a change is made to a utf8 table.

Is there a fix or is 5.6 to 5.1 not possible?

Upvotes: 1

Views: 2450

Answers (2)

Tinel Barb
Tinel Barb

Reputation: 141

MySQL 5.6.6 and up is using by default a CRC32 checksum for binlog records. In order to MySQL 5.1 and 5.5 to read the binlog, the master should be started with the variable

binlog-checksum = NONE

The variable is available at runtime also:

set global binlog_checksum='NONE';

The usual message is:

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Slave can not handle replication events with the checksum that master is configured to log;

It should be noted that the variable was introduced with MySQL 5.6.2 with the default value 'NONE'.

Reference

Upvotes: 0

Zafar Malik
Zafar Malik

Reputation: 6854

Mysql document did not say that different version replication is impossible but it says that lower version (master) to higher version (slave) is fine but there can be issues if you do vice versa.

Suppose there is some new functionality that is supported by newer version but not older version in that case when that statement will be replicated on older version then create problem.

For example stored procedures were introduced in 5.4 so if you are using this functionality in master 5.6 then it will create problem at the time of replication on 5.1 version.

another example can be of hot alter as it was introduced in mysql 5.6 which is default feature, so this can create problem (I did not check it just an example) if you replicate to older version before 5.6.

But here your issue seems different as you are saying that binary logs are showing currupted on even master which should not be due to different version replication. So first check what is the issue with your binary logs.

Even before attaching a slave just start your master after enabling binlog and try to read binglogs if everything is fine then you can try to attach a slave with it and can check if 5.6 to 5.1 replication is possible or not.

Upvotes: 1

Related Questions