MySQL Bugs: #43240: replication topology does not reflect changes

Bug #43240	replication topology does not reflect changes
Submitted:	26 Feb 2009 17:53	Modified:	3 Mar 2009 17:37
Reporter:	Scott Noyes	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Server	Severity:	S3 (Non-critical)
Version:	2.0.1.7125	OS:	Any
Assigned to:	Darren Oldag	CPU Architecture:	Any

Description:
Following change in replication, monitor does not show new topology correctly.

How to repeat:
Set up servers as follows:
db1 (master), db2 (slave #1), db3 (slave) and db5 (slave)

On db2, issue: CHANGE MASTER TO master_host="";
On db3 and db5, issue: CHANGE MASTER TO master_host="db2"; (plus other options to get correct binlog file and position).

Enterprise Monitor still shows db2 as a slave.

Suggested fix:
Bug appears related to still treating the former-slave-now-master as having slave data, and thus show his old slave status information.

Workarounds suggested are:

1) Stop the agent for db2, delete the db2 instance from the dashboard, and then restart the agent. This will lose history for the instance.

2) Stop tomcat, UPDATE inventory_instance_attributes SET supported=FALSE WHERE instance_id=<instance_id for mysql::slavestatus from diagnostic zip>; and restart tomcat. This will preserve history.

reproduced locally in development

a fix has been pushed into trunk.  however, this fix (along with the agent bug fix for bug#43239) will not fix a customer that is already in this situation.  it is only preventative so that the situation does not happen again.

the above mentioned workarounds are still valid to clean up customers that are already displaying incorrectly.

An entry was added to the 2.0.5 changelog:

Following a change in the replication configuration, MySQL Enterprise Monitor did not display the new topology correctly.