Description:
This is what I did to complete an upgrade from 4.1.20 -> 5.0.22:
1. started with a 'complete' install of 4.1 using 'Standard' server instance config
2. chose the default name 'mysql' for the server service -> completed successfully
3. stopped the server service
4. started 5.0 install as 'custom' and chose to install in the existing dir.
5. chose 'Reconfigure Instance' during server configuration, then standard config, and this kept the same default service name -> completed successfully.
Although this works you end up with the new installation in the old directory which is really not too tidy. I haven't tried renaming the dir to something more sensible after the install. At a minimum this would break any shortcuts to the executables, and would also likely require registry editing.
A much more sensible way to do this operation would be for the installation script to do some basic probing to detect what if any version is currently installed. If the current version is one that we are capable of performing an upgrade on, then the first screen of the install wizard should offer Upgrade as an option, "We have detected a previous installation of MySQL, do you wish to upgrade this installation or create a new installation?"
If 'New', then proceed as we are. If 'Upgrade', then uninstall the old version( backing up any values which must be retained first), and install the new version, renaming the directory in the process to a name which is more appropriate for the new version. Additionally, I'm unclear why we can't roll the table update step into the installation. It is a necessary part of the process so why not automate it, or at the least offer to automate it? i.e., "Your tables will need to be updated to take advantage of new features do you want to do that now?"
I'm sure there are a few snags that would have to be worked out along the way but I'm certain it couldn't be that hard since this is the way most companies do it.
What we have now is cumbersome, confusing as far as I can tell, only marginally documented. This seems to be to the most comprehensive doc we offer for upgrading Windows installations:
http://dev.mysql.com/doc/refman/5.0/en/windows-upgrading.html
Deficiencies in this doc include:
1. It is outdated, we haven't installed by default to the root of C:\ for a long time now.
2. It should break down upgrades into two distinct, comprehensive, and easy to follow paths:
a. new and distinct installation
b. a true upgrade/replace installation
In its current format questions arise at a number of different places.
1. why do I have to choose a 'custom' installation to do an upgrade? That doesn't seem normal.
2. why do I have to install my new version to a directory with an old version name? That doesn't seem normal.
3. How do I handle the server instance? The old one could have multiple names, and I can give the new one multiple names. What will be the results of my decision and what will I be left with at the end of it all?
4. What's the difference between 'reconfigure instance' and 'remove instance'. Although I can guess it's meaning in the context of a reinstall over a damaged installation, what does it mean if I'm doing an upgrade/replace?
5. Why at the end of it all do I have two installations present in 'Add/Remove Programs'? Does this mean that I can uninstall 5.0, and it will roll back to 4.1? Or, should I now uninstall 4.1 since all I care about is 5.0?
These are some of the big questions but there are more. Almost every screen you come to will have a questions associated that are not self-documented well enough, and not documented well enough in our manual.
This is a lot of information for one defect, but this is a general topic which really needs to be re-thought, and there is no way to make specific individual criticisms when the expected design is so poorly understood (by me).
In the end I spent a number of hours on a task which really shouldn't have taken more than 20 minutes, and much of that time was spent on pure experimentation. I don't think our customers will be happy with having to experiment with their MySQL installations, with the end result being that they simply won't upgrade.
How to repeat:
included above
Suggested fix:
included above
