MySQL Bugs: #42997: Replication discovery initial packet problem

Bug #42997	Replication discovery initial packet problem
Submitted:	18 Feb 2009 23:57	Modified:	22 May 2009 8:49
Reporter:	Adam Dixon	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Server	Severity:	S3 (Non-critical)
Version:	2.0.0.x, 2.0.4.x	OS:	Any
Assigned to:	Darren Oldag	CPU Architecture:	Any

Description:
If slavestatus is not present when for initial discovery, no subsequent checks are made for the host being a slave and is missed for replication discovery. (Never shows up in replication tab)

How to repeat:
Restarting tomcat may fix this.

the "broken initial discovery" may or may not be packet-split related (where the slavestatus inventory does not show up until AFTER the mysql::server inventory).

another common case I think I am seeing is where the mysql server is registered with the dashboard, but perhaps some other issue caused show slave status to fail (agent user with incorrect privileges, for example).

this other case still results in a server that doesn't realize it is a slave at initial discovery time, and if/when slavestatus does come in, we don't recognize it until a MEM server restart.

fix pushed to trunk (currently 2.1)

revision-id: oldag@mysql.com-20090325170024-oza9pza75syla4j2
parent: aggie@sun.com-20090325163205-gd6qk29migdui4th
committer: Darren L. Oldag <oldag@mysql.com>
branch nick: Trunk
timestamp: Wed 2009-03-25 12:00:24 -0500
message:
  http://bugs.mysql.com/bug.php?id=42997
  
  scheduled a list-instances(slavestatus) on a one minute
  frequency.  if a previously unknown slavestatus comes in,
  force a replcation manager rediscover of that server+slavestatus.

Patch installed in versions => 2.1.0.1020

pushed to 2.0 maintenance branch

revision-id: oldag@mysql.com-20090325201959-sqz39q8g1ng366lf
parent: oldag@mysql.com-20090324221614-xeaszjq5y7gqnu04
committer: Darren L. Oldag <oldag@mysql.com>
branch nick: TwoDotZero
timestamp: Wed 2009-03-25 15:19:59 -0500
message:
  http://bugs.mysql.com/bug.php?id=42997
    
  scheduled a list-instances(slavestatus) on a one minute
  frequency.  if a previously unknown slavestatus comes in,
  force a replcation manager rediscover of that server+slavestatus.

verified fixed in build 2.1.0.1020

verified fixed in build 2.0.6.7157

An entry was added to both the 2.0.6 and 2.1.0 changelogs:

If a host was not a slave during the initial discovery phase, then it would not be displayed in the Replication tab if it subsequently became a slave.

This was because after the initial discovery phase, if a host did not have slavestatus present, no subsequent checks were made to check for the host being a slave. It was therefore missed for the purposes of replication discovery and never showed in the Replication tab.