MySQL Bugs: #12814: Nonguarded option should be splitted into two ones

Bug #12814	Nonguarded option should be splitted into two ones
Submitted:	25 Aug 2005 19:43	Modified:	6 Dec 2007 15:28
Reporter:	Alexander Nozdrin	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	Instance Manager	Severity:	S4 (Feature request)
Version:		OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	Instance Manager

Description:
A server instance can be declared with "nonguarded" option in configuration file. That means that Instance Manager does not track this instance, i.e.:
  - IM doesn't start the instance at start;
  - IM doesn't restart the instance in case of failure;
  - IM doesn't stop the instance at shutdown (so, IM quits, the instance lives).

Actually, this "nonguarded" option is an attribute of an instance. It is specified once in configuration file and can _not_ be changed on the fly. So, it is impossible to declare an instance, which should not
be started on IM startup, but after manual startup becomes guarded.

How to repeat:
 

Suggested fix:
The idea is to introduce another option, which will define whether an instance should be started at
Instance Manager startup.

also see my latest comment here:
http://bugs.mysql.com/bug.php?id=14318

i believe there might be a need for multiple configuration parameters.

I support a change in how the Instance manager interacts with each instance. I spent two weeks trying to figure out what the logged MySQL_Instance_M access denied messages were from; I was quite surprised to find these were normal behavior. My normal reaction when I find an application log file saturated with access denied messages is to look for a problem. Learning that this was normal behavior only made me realize how unintuitive it was.

Unless connecting to a database requires significantly more resources than a failed attempt, I would suggest that the monitoring of an instance occur through some other means entirely, or through a documented, parameter-specified user in the database, one which should be set up with minimal privileges for this purpose only. (Could the password be extracted from the mysqlmanager.passwd file so it doesn't have to appear in my.cnf?) Lack of this supporting configuration should result in an error being recorded in the mysqlmanager log, and the instance being left unmonitored (but started and stopped appropriately). This would be much preferred over having to either sacrifice Instance Manager's monitoring (by setting the interval to a huge value, which I have done) or have instances unguarded, which is not acceptable since they aren't started.