MySQL Bugs: #41525: master_uuid discovery does not work with mysql

Bug #41525	master_uuid discovery does not work with mysql < 5.1
Submitted:	17 Dec 2008 0:07	Modified:	4 Mar 2009 10:07
Reporter:	Darren Oldag	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Agent	Severity:	S3 (Non-critical)
Version:	2.0.4.7141	OS:	Any
Assigned to:	MC Brown	CPU Architecture:	Any
Tags:	mem_20_maint, mem_crvu

Description:
I couldn't get master_uuid to ever show in in the agent/MEM communications.  I debugged through the agent code, and came across this:

	err = err || (lines != 15); /* for now we assume 5.1 format */

in the 5.0 master.info file, the lines is 14.  So, we failed.  Silently.  No log or error messages about being unable to read this file.

How to repeat:
start an agent against a replication slave mysqld 5.0 with agent debug logging.  let it discover against a MEM server.

look at the agent log, grep for master_uuid or inventory, notice no error messages, and also notice master_uuid is never reported.

Suggested fix:
put in switched logic for handling master.info formats for every mysqld version MEM supports.

Fixed in the launchpad tree. We have to merge it back.

Pushed to 2.0 and trunk/

revno: 1213
revision-id: jan@mysql.com-20090227214333-fdzmj73nv6s65l1h
parent: jan@mysql.com-20090227205320-85e9errvb1gcbbdr
committer: jan@mysql.com
branch nick: rel-2.0
timestamp: Fri 2009-02-27 22:43:33 +0100
message:
  added support for master.info from 4.1 and 5.0 (fixes #41525) [from lp:mysql-proxy]

revno: 1205
revision-id: jan@mysql.com-20090227214204-hu05jnsjsdlwbt96
parent: jan@mysql.com-20090227205140-dj6ozcrbgz1m9od5
committer: jan@mysql.com
branch nick: trunk
timestamp: Fri 2009-02-27 22:42:04 +0100
message:
  added support for master.info from 4.1 and 5.0 (fixes #41525) [from lp:mysql-proxy]

Verified fixed on 2.0.5.7148

On the agent logs monitoring a 5.0 mysqld we see

      <classname>slavestatus</classname>
      <instance>12515cdc-8c00-4223-9d2a-2666a403512c</instance>
      <attribute>Master_uuid</attribute>
     </target>
     <utc>2009-03-03T19:58:05.700Z</utc>
     <value>b2fd9f86-6e42-49f2-b930-e8fb3e728179</value>

An entry was added to the 2.0.5 changelog:

master_uuid discovery did not work with MySQL Server versions prior to 5.1. master_uuid did not show in any Agent to Monitor communications, and no log or error messages were generated.

However, now the bug has been fixed, an Agent monitoring a 5.0 MySQL Server would register the following in its logs:

...
 <classname>slavestatus</classname>
 <instance>12515cdc-8c00-4223-9d2a-2666a403512c</instance>
 <attribute>Master_uuid</attribute>
</target>
<utc>2009-03-03T19:58:05.700Z</utc>
<value>b2fd9f86-6e42-49f2-b930-e8fb3e728179</value>

Note the presence of master_uuid.