I am happy to announce that MariaDB 5.2.3 is now released as a stable release.
During the gamma period we did not receive any serious reports for issues in 5.2, so we are relatively confident that the new code is of decent quality.
You can read about the features of MariaDB 5.2 in my previous blog entry or in the fast growing MariaDB knowledgebase..
What is most interesting about MariaDB 5.2 is that most of the features came from the MariaDB/MySQL community, not from Monty Program Ab!
Without the community it would not have been possible to do a stable release so soon after the last release. Virtual columns, Extended User Statistics, Segmented MyISAM key cache, Pluggable Authentication, OQGRAPH and the Sphinx client are all from code provided by people outside of Monty Program Ab. Storage-engine-specific CREATE TABLE, Enhancements to INFORMATION SCHEMA.PLUGINS table and “Group commit” for the Aria engine were provided by us at Monty Program Ab.
Thanks also to all those who have reported and provided bug fixes for 5.1 and 5.2!
MariaDB 5.2.3 has all changes from MariaDB 5.1.50 and MySQL 5.1.51. (We are just about to release MariaDB 5.1.51)
Please report any issues to the MariaDB bugs database so that we can fix them!
We will continue to fix critical bugs in MariaDB 5.1, even if the
attention of bug fixes will now move to 5.2.
Now we are busy working on getting MariaDB 5.3 ready for beta. We have also started a merge of MariaDB 5.3 + MySQL 5.5 -> MariaDB 5.5 and hope to release this tree soon!
Happy database usage!
The intention from the start was to make upgrades to newer MySQL versions trivial. We have done a lot of work to keep data formats compatible (both in the .frm files and in the storage engines); when you install a new version of MySQL things should “just work”.
For a long time this was true, until MySQL 5.0 where we had to do some data incompatible changes, like in the way some characters were sorted and how end-of-line blanks were stored in indexes.
To make the upgrade process easy, we created the ‘mysql_upgrade’ program which should detect possible incompatible tables and automatically convert data as needed.
The full upgrade process (for your data) should always be as simple as:
- Install your new MariaDB / MySQL version.
- Start the mysqld server.
- Run mysql_upgrade.
Unfortunately, over time something has gone wrong. We found this out when a user recently tried to upgrade a big installation from MySQL 5.0 to MariaDB. The issues encountered included:
- Tables with long names were not converted to the new 5.1 name format
- Some InnoDB tables failed with the error: “Table upgrade required; Please do “REPAIR TABLE `xxx`” or dump/reload to fix it!”
- The same failure for all ARCHIVE tables
- Some strange error messages for some internal system tables
So the upgrade process for this user was actually:
- Install the new MariaDB / MySQL version.
- Start the mysqld server
- Run mysql_upgrade
- Make a list of all tables that failed to upgrade.
- Reinstall the previous MySQL version.
- Dump the problem tables with mysql_dump
- Remove the dumped tables.
- Install the new MariaDB / MySQL version again.
- Load the dumped tables.
- Test that nothing was missed with ‘mysql_upgrade –force’
We learned about the above problems on the #maria IRC channel and within 24 hours we had fixed all of the issues. We are happy to announce the full upgrade process is once again just the three step: Install new version, Start mysqld, Run ‘mysql_upgrade’.
We also added more options to mysql_upgrade and mysqlcheck (which is used by mysql_upgrade) to make it easier to find out what is happening if something does go wrong.
As part of the process (and to document the changes) we also added some new articles to our Knowledgebase about
upgrading from MySQL 5.0, mysql_upgrade and mysqlcheck.
We hope all the above will make the upgrade process much easier and more reliable for everyone!