MySQL Bugs: #70507: MEM should treat a rebuilt MySQL server as a continuation of the previous one

Bug #70507	MEM should treat a rebuilt MySQL server as a continuation of the previous one
Submitted:	3 Oct 2013 10:14	Modified:	9 Jan 2015 10:16
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Configuration	Severity:	S3 (Non-critical)
Version:	all versions to 3.0.1.2893	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	windmill

Description:
Similar to bug#52403.

Sometimes it is necessary to rebuild a db server monitored by MEM. This may be due to breakage and it may be due to for example an OS upgrade. The old MEM information may be lost because of this rebuild.

Currently MEM treats this new server as being completely different as the server uuid is different and hence it considers the server to be different. Yet in many cases if the hostname is unchanged this box is considered by its users as the same server as before, and when the MySQL server is reinstalled we want to view the history of the server's details but also the MySQL details as before, as a single history.

MEM treats these as 2 instances and thus gives you 2 histories, rather than noting that maybe the OS version has changed or the MySQL version has changed, or the filesystem has changed etc...

How to repeat:
See above.

Suggested fix:
If this behaviour breaks existing installations make it a site-wide configuration option.

However allow:
1. a rebuilt server to be recognised as the same server (perhaps using its FQDN as a clue), so that history for this server is maintained.
- perhaps if the uuid issue is important inside merlin get the dashboard to tell the agent to update its uuid to the one known previously.
2. for any mysql instances that might be seen by the agent
- if the uuid does not match, or matches that of another known server currently the agent gets upset and shuts down.
- change this so that if the agent / dashboard knew about a mysql server on the local server (using the same datadir as previously) then it must be the same "instance" as before, and again if needed, tell the agent to update the instances identity to the one known before.
- this will then allow a complete history to be kept for this server.

Note: these changes reduce the need to work around the current setup which should not be necessary.
The fact that duplicate instances show up in the dashboard with the old ones showing up as "red is dead" is an indication that something is wrong, and all the work arounds to avoid the agent dying or committing suicide because it's been told it's talking to a duplicate instance would go away.

I think that bug#52403 is a symptom of this bug report.

There may be reasons when you do want to migrate histories, such as when changing a master server to a new server (hardware upgrade) but you want to consider the history of the "master" as separate continuous thing but other than that I'm inclined to think that the migration is only because the history is there but MEM insists it is not for the same "instance" or "server" when from the users' point of view it is the same "system".

Hello Simon,

Thank you for the bug report.

Thanks,
Umesh