I generally find MySQL Sever sufficiently tested, meaning at least minor version upgrades rarely cause the problems. Of course it is not perfect and I remember number of big issues when some releases could not be used due to behavior changes in them and when something had to be rolled back in the next release.
But generally I think MySQL is doing much better than a lot of other projects in this respect.
Major version upgrades become more painful recently. In MySQL 3.22->3.23 upgrades or 3.23->4.0 upgrades you really could just swap binary and try out new version and if you need to get back you just swap binaries to the old version. I think it was great.
In MySQL 4.1 and later more caution is required because you could screw your data, for example by specifying utf8 as default character set together not to mention infamous timestamp format change which forced to change a lot of applications.
MySQL 5.0 added more issues to the pile with a lot of data type and sort order related changes, this is why long needed CHECK FOR UPGRADE was added in the newer versions and why number of people established slow by safe upgrade procedures – dump your data and reload.
Little tip to mention – upgrading to the new major version make sure you upgrade to latest current version at first. Ie upgrade to recent MySQL 5.0 before upgrading to MySQL 5.1 – this makes sure you will be at somewhat tested upgrade/downgrade path and your chances of successful downgrade if having problems with new major release will increase significantly. Making sure you can afford mysqldump and reload in worse case scenario is also good idea.
Anyway I was going to write not about MySQL Server upgrade process but rather about my experience with RPM scripts used during install and upgrade. These are obviously not part of automated mysql-test process and I’m wondering if they are tested at all.
For example if you use RHEL4 in default configuration (which is having SELinux enabled) upgrading RedHat RPM to MySQL “RedHat” RPM will not allow MySQL to start because SELinux will not let it. In some cases you will not even get server logs created because SELinux restricts console output as MySQL changes name to “mysql”.
Come On, as I remember MySQL And Redhat should be partners or is this partnership happening in area of marketing and taking money from the customers and have limited technical side ?
Today I spent another quite a while trying to Upgrade RedHat RPM binaries to MySQL Community RPM. Of course you may argue MySQL is not responsible for upgrade process from some “third party” binaries but I would argue they should as it is most common process – you get RedHat or Fedora which comes with MySQL binary and if you’re standard MySQL user you would just use that RPM and only upgrade it to something else if you need it for any reason. And this path does not work that great.
I logged some of my experiences as a bug but here are some more details about the problems
Upgrade Script fails to shut down MySQL Server. Obviously nothing can work without this one.
Upgrade Script Removes /var/lib/mysql symlink I’m not sure what is the problem about having this a a symlink – I like this approach a lot because it allows you to have database logically in same standard location while move it around as you seem suits. But even if there is the reason removing symlink on upgrade is just bad idea – it would be much better to tell me it is not supported any more so I go and change my environment instead of just finding it broken by upgrade. Not to mention it may be scary to find /var/lib/mysql gone.
If I’m not mistaken in one other instance I had new /var/lib/mysql created (probably when I retried second time) – this is even more scary to get running MySQL but find the database is gone now.
mysql user removed I’m not sure if this one is done by RedHat uninstall script or MySQL install script but simply I find no mysql user after upgrade.
MySQL Does not start after upgrade This is simply result of upgrade. Obviously with symlink removed
I can’t call myself a best expert in RPM out where but this was pure “rpm -Uvh MySQL*” in the directory with few downloaded MySQL binaries so it should be pretty straightforward.
