MySQL Bugs: #68164: MySQL 5.6: Version mismatch a bit alarming when master is not 5.6

Bug #68164	MySQL 5.6: Version mismatch a bit alarming when master is not 5.6
Submitted:	24 Jan 2013 13:14	Modified:	3 Apr 2013 13:42
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	5.6.9-rc	OS:	Any
Assigned to:	Luis Soares	CPU Architecture:	Any

Description:
After upgrading a slave to 5.6.9-rc from 5.523, the master still runs 5.5 I see:

2013-01-24 13:18:40 28611 [Warning] Slave I/O: Unknown system variable 'SERVER_UUID' on master, maybe it is a *VERY OLD MASTER*. Error_code: 1193

Text is copied exactly as is from the logs.

This is rather alarming and I don't think it should be so dramatic as it's likely to worry people. When doing an upgrade initially you expect the master to be on a version behind the newly upgraded slave.

How to repeat:
Install a master / slave pair with 5.5. then upgrade the slave to 5.6 and look at the message when replication restarts.

Note: nothing breaks but the message is worrying. It should not be.

Suggested fix:
In fact since you try to check SERVER_UUID, why don't you check VERSION first and then you know for certain, there's a major version mismatch between master and slave and then you can say something much less alarming like:

[Warning] Slave I/O: Unknown system variable 'SERVER_UUID' on master, which is running a pre-mysql 5.6 version: 5.5.23. Error_code: 1193

That's clear, and confirms the master/slaves run different versions.

Thank you for the bug report. Verified by code inspection.

A couple of notes on this:

We actually do the version checking before trying to get the master_uuid:

  ret= get_master_version_and_clock(mysql, mi);
  if (!ret)
    ret= get_master_uuid(mysql, mi);
  if (!ret)
    ret= io_thread_init_commands(mysql, mi);

  if (ret == 1)
    /* Fatal error */
    goto err;

  if (ret == 2) 
  { 
    if (check_io_slave_killed(mi->info_thd, mi, "Slave I/O thread killed"
                              "while calling get_master_version_and_clock(...)"))

Note, we set ret a number of times during this process, however in the final message printed, we state it's a problem calling get_master_version_and_clock(), only, whilst functions such as get_master_uuid() can also set ret to 2. 

It seems there is some precedence to the emphasis in these kinds of errors, we have done the same for server_id and collation_server:

    mi->report(WARNING_LEVEL, ER_UNKNOWN_SYSTEM_VARIABLE,
               "Unknown system variable 'SERVER_ID' on master, \
maybe it is a *VERY OLD MASTER*.");

      mi->report(WARNING_LEVEL, ER_UNKNOWN_SYSTEM_VARIABLE,
                 "Unknown system variable 'COLLATION_SERVER' on master, \
maybe it is a *VERY OLD MASTER*. *NOTE*: slave may experience \
inconsistency if replicated data deals with collation.");

However, these were all there pre-5.0, so somewhat warranted. In the case of the master_uuid, I agree with the above, we should not put that kind of emphasis on it, and be more descriptive in which versions are required/used.

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

Fixed in 5.6+. Documented in the 5.6.11 and 5.7.1 changelogs as follows:

        When replicating to a MySQL 5.6 master to an older slave, Error
        1193 (ER_UNKNOWN_SYSTEM_VARIABLE) was logged with a message such
        as -Unknown system variable 'SERVER_UUID' on master, maybe it is
        a *VERY OLD MASTER*.- This message has been improved to include
        more information, similat to this one: -Unknown system variable
        'SERVER_UUID' on master. A probable cause is that the variable
        is not supported on the master (version: 5.5.31), even though it
        is on the slave (version: 5.6.11)-
      
Closed.