MySQL Bugs: #49749: InstanceConfig cannot detect service removal, does not offer datadir option

Bug #49749	InstanceConfig cannot detect service removal, does not offer datadir option
Submitted:	16 Dec 2009 21:52	Modified:	12 Apr 2011 14:47
Reporter:	Peter Brawley (Basic Quality Contributor)	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S2 (Serious)
Version:	5.6.2	OS:	Windows (winXP)
Assigned to:	Iggy Galarza	CPU Architecture:	Any
Tags:	qc

Description:
5.5 installs itself not as an update to 5.4 (which it properly is, "milestone 2" following "milestone 1", as the 5.5 documentation states clearly), but as a brand new instance of MySQL. But it proposes to name its service "MySQL", so if there is an existing MySQL service, MySQLInstanceConfig.Exe cannot install a service under that name.

So when one reaches that point with MySQLInstanceConfig and an existing 5.4 installation, the natural thing to do is to delete the existing MySQL service by opening a command window and issuing ...

sc delete mysql

That removes the service, but InstanceConfig remains ignorant of the fact. One has to abort InstanceConfig and start all over again. 

How to repeat:
As above

Suggested fix:
Most installations of 5.5 will be on machines already running 5.4. MySQLInstanceConfig.Exe should handle this difficulty automatically.

Thank you for the bug report.

This bug report along with it's proposed fix have been evaluated by the Windows Experience Team, who have decided it can't be fixed.  From the perspective of the Windows installer, MySQL 5.4 and MySQL 5.5 are different products just like MySQL 4.1 and 5.0 are different products.  Because both 5.4 and 5.5 packages have already been made available publicly there is no way to change this behavior that doesn't introduce other more serious problems.

> This bug report along with it's proposed fix have been evaluated by the
> Windows Experience Team, who have decided it can't be fixed.  

Unfortunate.

At least document the problem!

For installing MySQL 5.6 in the presence of 5.5, this problem remains: when InstanceConfig reports that it cannot create a new MySQL service in the presence of an existing one, the user naturally opens a sommand window to delete the existing service, but InstanceConfig remains ignorant of the fact. One must abandon InstanceConfig and start all over again. 

That is user-hostile. At the very least, IC should offer a reasonable excuse and/or an apology for this stupidity.

And why, on upgrade, doesn't MySQLInstanceConfig give the user an opportunity to set datadir!? The default behaviour looks designed to deliberately ignore any previous datadir setting, to deliberately lose previous data. It's bizarre.

There is another 5.5-to-5.6 issue here. InstanceConfig does discover previous InnoDB data paths, and offers them to the user as choices. If you choose one that has InnoDB datafiles, InstanceConfig configures MySQL to use that InnoDB data folder. The new datadir, however, has no ib_logfile entries, so the server crashes.

1. This needs to be fixed.

2. If InstanceConfig can find previous InnoDB data folders, why can't it find previous datadirs?