MySQL Bugs: #50298: slave agent only looks for master.info in data directory

Bug #50298	slave agent only looks for master.info in data directory
Submitted:	13 Jan 2010 4:37	Modified:	11 Jan 2011 17:52
Reporter:	Shannon Wade	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Agent	Severity:	S3 (Non-critical)
Version:	2.1.0.1096	OS:	Any
Assigned to:	Michael Schuster	CPU Architecture:	Any

Description:
When agent tries to discover master it looks for master.info in the data directory (/usr/local/mysql/data by default or defined with --datadir), then uses that to login to master and read mysql.inventory for the master uuid. This breaks if MySQL is started with master-info-file and it is located somewhere else, agent still looks for master.info in datadir.

Agent debug will show something to this effect:

2010-01-12 08:52:52: (warning) job_collect_mysql.c:484: g_mapped_file_new(/data01/mysql/cmsdb-dev/data//master.info) failed: Failed to open file '/my/non/default/data/directory/master.info': open() failed: No such file or directory

Failing to do that it will fall back to information gathered from show slave status. This method fails in some cases with natted masters and slave, two instances on same master bound to different ips but same port,etc.

How to repeat:
Set master-info-file to something. Agent will fail to use 1st method (master.info and uuid from master mysql.inventory)

In order to manifest as a problem, master has to using situation where 2nd method (using slave status) would fail for example two masters on the same box but bound to different ip addresses.

Then on the slave use master-info-file set to a different path than default so that agent falls back to 2nd method.

Suggested fix:
No suggestions. This is not shown in global variables nor slave status, so I'm not sure.

If you encounter this though removing master-info-file so that the data directory is used will fix.

Mark Leith writes: 
Also see http://bugs.mysql.com/bug.php?id=50316

Please understand why I'm writing this comment in here.

AFAIK the agent currently uses this information to try and get the slave's replication credentials and then to login to the master server using those credentials to get information on mysql.inventory.

This is extremely bad etiquette, impersonating another "user". The mysqld replication user is supposed to be talking to the master with these credentials.

If the agent wants to talk to the master then it should be given specific credentials to obtain the specific information it needs. Unfortunately this information is currently not available to the agent.

Therefore I would recommend rather than look for the mysqld's master.info file you fix the agent and ensure that the DBA/sysadmin provides credentials to access the master server.

Current behaviour is very antisocial.

I have already complained about this before in the Enterprise ticketing system, but you guys don't "get it". Give me your credit card numbers and let me go shopping....

PLEASE fix the behaviour cleanly and if nothing else login with the username provided by the current agent credentials, and to the master server as provided by the master.info. That at least is slightly better.

See: https://support.mysql.com/view.php?id=43220

Mark Leith writes: 
Please see http://bugs.mysql.com/bug.php?id=50604 for a feature request to disable using the master.info file. This bug is related to not being able to use the feature properly when --master-info-file is set.

Added to 2.2.0 change log:

The master.info file was not located properly if the MySQL server was
started with the --master-info-file option.

The specifics of how the file is located weren't documented in the MEM manual, so there is no doc impact beyond the change log.