Bug #79272 MySQl 5.5 master fails to replicate to MySQL 5.7.9
Submitted: 13 Nov 2015 14:08 Modified: 13 Nov 2015 14:30
Reporter: Muhammad Irfan Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Replication Severity:S2 (Serious)
Version: OS:Linux
Assigned to: CPU Architecture:Any

[13 Nov 2015 14:08] Muhammad Irfan
Description:
When trying to replication from MySQL 5.5 (master) to MySQL 5.7.9 (slave) slave server IO thread can't connect to master and failed as below:

Fatal error: The slave I/O thread stops because a fatal error is encountered when it tries to get the value of SERVER_UUID variable from master.

How to repeat:
MySQL 5.7.9-log slave:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State:
. 
               Connect_Retry: 60
              Master_Log_File: master-bin.000001
          Read_Master_Log_Pos: 279
               Relay_Log_File: centos63-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File: master-bin.000001
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
.
.
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1593
                Last_IO_Error: Fatal error: The slave I/O thread stops because a fatal error is encountered when it tries to get the value of SERVER_UUID variable from master.
               Last_SQL_Errno: 0
.
.
MySQL 5.5 master:
+---------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for repl@192.168.0.130                                                                                                                           |
+---------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.0.130' IDENTIFIED BY PASSWORD '*A25F97037BF97C19A2E88CF7891C5C2038C039' |
+---------------------------------------------------------------------------------------------------------------------------------------------------------+

related general log entries from master server:
151113 18:19:50    21 Quit
151113 18:20:23    22 Connect   repl@192.168.0.130 on
                   22 Query     SELECT UNIX_TIMESTAMP()
                   22 Query     SELECT @@GLOBAL.SERVER_ID
                   22 Query     SET @master_heartbeat_period= 30000001024
                   22 Query     SET @master_binlog_checksum= @@global.binlog_checksum
                   22 Query     SELECT @@GLOBAL.GTID_MODE
                   22 Query     SELECT @@GLOBAL.SERVER_UUID
                   22 Quit
[13 Nov 2015 14:30] Miguel Solorzano
Thank you for the bug report. behavior expected according documented.

https://dev.mysql.com/doc/refman/5.7/en/replication-compatibility.html

" MySQL supports replication from one release series to the next higher release series. For example, you can replicate from a master running MySQL 5.5 to a slave running MySQL 5.6, from a master running MySQL 5.6 to a slave running MySQL 5.7, and so on.

However, you may encounter difficulties when replicating from an older master to a newer slave ...."

https://dev.mysql.com/doc/refman/5.7/en/replication-options.html

"When using MySQL replication, masters and slaves know each other's UUIDs. The value of a slave's UUID can be seen in the output of SHOW SLAVE HOSTS. Once START SLAVE has been executed, the value of the master's UUID is available on the slave in the output of SHOW SLAVE STATUS. "

 Last_IO_Error: Fatal error: The slave I/O thread stops because a fatal error is encountered when it tries to get the value of SERVER_UUID variable from master.
[26 May 2016 14:23] IGG t
Are we likely to get a fix for this BUG (disable looking for master_UUID or similar), as until I am able to install and adequately test a 5.7 slave I'm unable to upgrade from my current 5.5 databases.
[17 Oct 2016 14:59] Przemyslaw Malkowski
Seems that this one was already fixed in https://bugs.mysql.com/bug.php?id=80962 ...