MySQL Master 5.5 - Slave 5.6 - unknown system variable 'binlog_checksum', Error_code: 1193

Question

I see the below warning on the my slave server:

2016-11-18 22:48:03 12808 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
2016-11-18 22:48:03 12808 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.018098' at position 920330293, relay log '/mnt/data/mysql/mysqld-relay-bin.318142' position: 473446279
2016-11-18 22:48:03 12808 [Note] Slave I/O thread: connected to master 'repl@xxx:3306',replication started in log 'mysql-bin.018103' at position 271452699
2016-11-18 22:48:03 12808 [Warning] Slave I/O: Notifying master by SET @master_binlog_checksum= @@global.binlog_checksum failed with error: Unknown system variable 'binlog_checksum', Error_code: 1193
2016-11-18 22:48:03 12808 [Warning] Slave I/O: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.5.42-log), even though it is on the slave (version: 5.6.31-log), Error_code: 1193

1. From what I understand it is happening when master is not compatible with the 5.6 slave, is it correct ?
2. Should I ignore these warning ? if not How do I fix this without damage anything the MYSQL MASTER ?

Master version:

Variable_name            Value                         
-----------------------  ------------------------------
innodb_version           5.5.42                        
protocol_version         10                            
slave_type_conversions                                 
version                  5.5.42-log                    
version_comment          MySQL Community Server (GPL)  
version_compile_machine  x86_64                        
version_compile_os       Linux         

Slave version:

Variable_name            Value                         
-----------------------  ------------------------------
innodb_version           5.6.31                        
protocol_version         10                            
slave_type_conversions                                 
version                  5.6.31-log                    
version_comment          MySQL Community Server (GPL)  
version_compile_machine  x86_64                        
version_compile_os       Linux      

Thanks !

Answer 1

If your run SHOW SLAVE STATUS\G on the Slave, and you see Slave_IO_Running: Yes, then the IO Thread is fine.

Notwithstanding, please note the Warnings

2016-11-18 22:48:03 12808 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0

Error Code 0 means it's not an error, just informational.

2016-11-18 22:48:03 12808 [Warning] Slave I/O: Notifying master by SET @master_binlog_checksum= @@global.binlog_checksum failed with error: Unknown system variable 'binlog_checksum', Error_code: 1193

You mentioned the error involves the variable binlog_checksum.

According to the MySQL Documentation for binlog_checksum

Enabling this option causes the master to write checksums for events written to the binary log. Set to NONE to disable, or the name of the algorithm to be used for generating checksums; currently, only CRC32 checksums are supported. As of MySQL 5.6.6, CRC32 is the default.

This option was added in MySQL 5.6.2.

Since your Master is 5.5.42, there is no binlog_checksum available to compare the Master to the Slave. The warning is valid.

Perhaps setting binlog_checksum to 'NONE' on the Slave might disable this check.

2016-11-18 22:48:03 12808 [Warning] Slave I/O: Unknown system variable 'SERVER_UUID' on master. A probable cause is that the variable is not supported on the master (version: 5.5.42-log), even though it is on the slave (version: 5.6.31-log), Error_code: 1193

This is the same problem. The option server_uuid does not exist in MySQL 5.5.42 (the Master) as the message itself says.

EPILOGUE

As long as replication is running you are OK for the moment. It strongly recommend get your Master to MySQL 5.6.31 ASAP. Why ?

MySQL 5.6 introduced microseconds to DATETIME. If the Master (5.5.42) sends a DATETIME to the Slave (5.6.31), the IO Thread will break immediately. Please read my post from 2015-01-02 where I mentioned this.

You could work around this DATETIME mess by switching to STATEMENT replication (setting binlog_format to STATEMENT) on both Master (5.5) and Slave (5.6).