MySQL 5.5 to 5.7 doesn't work, apparently this is a feature?

Question

Has anyone found a way yet of circumventing MySQL 5.7s insistence that it's Master must have a server_UUID.

I currently have multiple instances of MySQL 5.5 over various sites, and want to look at upgrading to MySQL 5.7. To do this I was planning to set up a test-site using some MySQL 5.7 databases running as a set of master > slaves from my main site.

But this failed at the first hurdle, as MySQL 5.7 insists that the Master must have a SERVER_UUID !! Depsite the official documentation telling us we should upgrade our slave databases before we upgrade the master.

In other words, when upgrading to MySQL 5.7, the slaves must be MySQL 5.7 before you can upgrade the master to 5.7.

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

As it stands the only option appears to be to install, configure, and test a copy of MySQL 5.6 (which I'll never actually use) to act as an itermediary between my live system and test system. But that just introduces a whole load of additional complexity when trying to run like for like testing between 5.5. and 5.7 slaves (e.g. is it MySQL 5.7 that caused problem X, or was it MySQL 5.6 doing something on the way through etc).

I see that there is a BUG report for this, which they have since decided is Not actually a BUG, but a feature!!!

Answer 1

The problem is that MySQL 5.5 does not support GTIDs, but MySQL 5.7 does and have it activated by default.

As the MySQL manual suggests, you can disable GTIDs on the 5.7 slaves to perform your tests, and later, when all your servers will be upgraded to 5.7, activate GTIDs on both master and slaves.

see http://dev.mysql.com/doc/refman/5.7/en/replication-upgrade.html for more information.

If you are upgrading an existing replication setup from a version of MySQL that does not support global transaction identifiers to a version that does, you should not enable GTIDs on either the master or the slave before making sure that the setup meets all the requirements for GTID-based replication. For example server_uuid, which was added in MySQL 5.6, must exist for GTIDs to function correctly. See Section 18.1.3.2, “Setting Up Replication Using GTIDs”, which contains information about converting existing replication setups to use GTID-based replication.

Answer 2

----- 2014-09-25 5.7.5 Milestone 15 -- Functionality Added or Changed -- Replication -----

When replicating from a master running a version earlier than MySQL 5.6.0 to a slave running MySQL 5.6.0 or later, the slave requires the master_uuid value, which is the server_uuid ( http://dev.mysql.com/doc/refman/5.7/en/replication-options.html#sysvar_server_uuid ) value from the master. The master_uuid value is unsupported on the older master, and in such a replication situation could become invalid on the newer slave. A check for empty master_uuid now ensures that the slave uses an empty value for master_uuid. (Bug #18338203)