Fatal error trying to sync Percona 5.7 Slave to mysql 5.5 Master

[ReluctantDBA]

Hope someone out there can help me. I’m in the middle of an upgrade to Percona 5.7 by using the replication method (see further background below if needed). Everything worked fine until I started replication and I got the following error:

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.

The Master in question is a mysql Community 5.5.45 Server.

Does anyone know if what I am trying to do is impossible or whether there is something I can do to get this replicated?

Things I have checked already are checking the repl_user credentials by accessing mysql command line remotely from the slave to the master - that was ok.
And the iptables logs show that nothing is being blocked either way.

It is a big database and took over 12 hours to import so I hope I don’t have to do this again!

Any suggestions would be greatly appreciated.

Further Background:
The first replication migration I did was loosely based on this process: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html because I was moving to RDS.
That worked fine.
Later I upgraded a Percona 5.6 server to Percona 5.7 by using a modified version of this process, obviously to use mysql commands instead of RDS commands, but still essentially the same process: full sqldump, scp to new server, source the file to import it, replicate to bring back in sync then switch DNS to the new server.
Again, that went well.

[ReluctantDBA]

Further error messages from the mysqld.log when I started the slave:

2016-03-16T20:30:55.151703Z 2 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use ‘–relay-log=db02-new-relay-bin’ to avoid this problem.
2016-03-16T20:30:55.637309Z 2 [Note] ‘CHANGE MASTER TO FOR CHANNEL ‘’ executed’. Previous state master_host=’’, master_port= 3306, master_log_file=’’, master_log_pos= 4, master_bind=’’. New state master_host=’’, master_port= 3306, master_log_file=‘mysql-bin.000028’, master_log_pos= 107, master_bind=’’.
2016-03-16T20:31:26.080469Z 0 [Note] InnoDB: Buffer pool(s) load completed at 160316 20:31:26
2016-03-16T20:32:01.200236Z 3 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the ‘START SLAVE Syntax’ in the MySQL Manual for more information.
2016-03-16T20:32:01.202183Z 4 [Warning] Slave SQL for channel ‘’: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
2016-03-16T20:32:01.202260Z 4 [Note] Slave SQL thread for channel ‘’ initialized, starting replication in log ‘mysql-bin.000028’ at position 107, relay log ‘./db02-new-relay-bin.000001’ position: 4
2016-03-16T20:32:01.211896Z 3 [Note] Slave I/O thread for channel ‘’: connected to master ‘repl_user@:3306’,replication started in log ‘mysql-bin.000028’ at position 107
2016-03-16T20:32:01.213027Z 3 [Warning] Slave I/O for channel ‘’: Notifying master by SET @master_binlog_checksum= @@global.binlog_checksum failed with error: Unknown system variable ‘binlog_checksum’, Error_code: 1193
2016-03-16T20:32:01.213451Z 3 [ERROR] Slave I/O for channel ‘’: 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. Error_code: 1593
2016-03-16T20:32:01.213462Z 3 [Note] Slave I/O thread exiting for channel ‘’, read up to log ‘mysql-bin.000028’, position 107

[jrivera]

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

"

[ReluctantDBA]

Thanks jrivera. I read that but I thought it was non-committal. It didn’t say you couldn’t jump two releases.
Anyway I just upgraded to 5.6 in the end (which worked well using that method) and will do it all over again to upgrade to 5.7 with minimal downtime.
Often when vendors say that something isn’t supported (which they don’t explicitly say), it doesn’t mean that it won’t work. I’ve got lots of unsupported configurations to work. I just can’t get support on them.
The crux of the matter seemed to be 5.7’s insistence that there was a SERVER_UUID and I felt sure that the replication would have worked if I could get past that obstacle.
Oh well, I’ll get there in the end, even if it does mean a couple of extra nights work.

Thanks.