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.


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!!!

  • Add a comment to that bug, to complain about it.
    – Rick James
    Jun 4, 2016 at 16:37
  • I left a comment, but there was no answer. However, in the latest release (5.7.13) that [Not a] BUG has been fixed! ! ! and it now works.
    – IGGt
    Jun 6, 2016 at 7:16

2 Answers 2


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, “Setting Up Replication Using GTIDs”, which contains information about converting existing replication setups to use GTID-based replication.


----- 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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.