Slave can not handle replication events with the checksum that master is configured to log

 

关于数据库升级：
数据库由5.5升级到5.7， 从库升级到5.7后挂载在主库5.5没问题，但是当切换的时候， 5.5 挂载5.7的时候报错

错误日志： 
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; the first event 'mysql-bin.000005' at 154, the last event read from '/export/data/mysql/mysql-bin.000005' at 123, the last byte read from '/export/data/mysql/mysql-bin.000005' at 123.' 

经查是由于mysql主从在 binlog校验上出的问题； 
在v5.6.6之前， mysql为了保证BINLOG数据从主库传到从库的一致性，默认只检查每个事物的长度是否匹配，匹配则成功，不匹配则主从同步会失败。

在mysql 5.6.2之后，为了保证数据的安全性引入了新功能binlog_checksum，该功能用于对主库同步过来的事物进行CRC32校验，确保事物没有被篡改；(CRC校验码相同则该事物同步成功，不同则同步失败报错)；并且在v5.6.6版本之后默认为CRC32；
修改binlog_checksum ='NONE' 可以5.5挂5.7挂上去； 但当master flush logs;的时候还是由于版本问题报错；

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.

如果直接一次性升级有无法回滚的风险；建议还是需要主从都升级到5.6，后续再升级到5.7；