Some of you may already notice, that in Build Service, there are already available rpms for new MySQL 5.1. Currently I think that in openSUSE 11.2 will be some 5.1 version of MySQL. So it may be interesting to tell our users what will change and how. Most of these changes are reflected in README.SuSE, but frankly – who reads READMEs?
Changes
Plugins
One of the new features in MySQL 5.1 is support for plugins. So some of the storage engines will be now shipped like that. Following plugins will be available:
- archive
- blackhole
- federated
- example
As you can see, InnoDB will be still compiled as internal part of MySQL. If you are upgrading from version 5.0.X or if this is your first installation of MySQL 5.1, all plugins will be enabled by default and you can disable them manually later (see manual). All these plugins are installed by main mysql rpm so you don’t need to install anything special. And if you don’t like them, you can disable them easily and completely 😉
With this change you need to remove skip-federated option from your my.cnf file if you have changed it manually. This option was there by default in previous versions of MySQL. But if you are installing MySQL for the first time or if you didn’t touch your configuration file, everything should be ok.
File locations
There are going to be some changes in files locations too. Most of them was made in default configuration file so if you are experiencing problems and you have made some manual adjustments to your /etc/my.cnf, try to merge this file with /etc/my.cnf.rpmnew.
First of them is that mysql socket file and pid file were moved by default from /var/lib/mysql to more reasonable location ( /var/run/mysql ). Second change is that mysql log file is again back in /var/log. These changes should make MySQL more LSB friendly and help people with their MySQL administration. All these changes can be reverted by changing MySQL configuration file so if you don’t like it, you can move them anywhere you want 😉
BerkeleyDB
Other important change is that MySQL no longer contains BerkeleyDB as storage engine. There is no fix for that and if you used it before, you have to migrate your data to different storage engine.
MySQL Upgrade Log
Last thing you may find useful is that if you missed messages displayed during automatic MySQL database upgrade, you can find them from now on in /var/log/mysql_upgrade.log.
Summary
Just summarization of what you can expect. You wouldn’t be able to use BerkeleyDB any longer. And if you are experiencing any problems, it’s probably because you changed your configuration manually so solution is to replace /etc/my.cnf by /etc/my.cnf.rpmnew