Today we’re pleased to announce the availability of MariaDB Galera Cluster!

With this release, we’re addressing the numerous requests we’ve received over the past few months for a MariaDB-based Galera Cluster. MariaDB, the more reliable, performant, feature-complete & backwards compatible MySQL database becomes even more attractive by making it available for Galera Cluster.

What is it?

  • A straight merge of MariaDB 5.5.25 with Galera Cluster by Codership
  • An alpha release which should not be used in production environments
  • Using the Galera replication methodology, users get:
    • Synchronous, multi-master replication with guaranteed data consistency
    • This solution provides both read & write scalability

MariaDB Galera Cluster is fully data-compatible with MariaDB or MySQL, as it will work with the standard databases created by these products. There are next to none or very minimal application changes that are required to make the solution work.

Where can I get it?

What’s next?
The plan is for a rapid release cycle to heavily test the performance and usage of MariaDB Galera Cluster in different environments. Please file bugs at:

Seppo Jaakola, CEO for Codership
“It’s great that we are working closely with an upstream provider of a MySQL-compatible binary, MariaDB. We no longer have to spend time coding against out-of-tree changes as we’re part of MariaDB,” stated Jaakola. “The excellent MariaDB engineering team constantly releases new versions of MariaDB with high quality assurance (QA). Codership will continue to collaborate closely with the MariaDB engineering team to improve the product and make new versions of the MariaDB Galera Cluster available.” he continued.

Michael “Monty” Widenius, CEO for Monty Program Ab
“We’ve received a significant amount of requests for a MariaDB based Galera cluster and today we’re proud to deliver that. We’re currently preparing ourselves and our partners for a rollout of the GA product and related professional services via SkySQL to run critical systems on top of MariaDB Galera Cluster.”


The MariaDB Team will together with Codership work on customer requests and demands in the areas of cluster and replication. Please contact us if you are interested in any services we can offer around Galera, MariaDB or MySQL.

In end of May I told about the numbering plans for the next version of MariaDB in the blog post What comes in between MariaDB now and MySQL 5.6?. We received quite a lot of feedback and criticism on the idea of calling the next version MariaDB 10.0. Here is a little more information about why it makes sense to call the next version 10.0.

This is not news for most of you. MariaDB is not just a set of patches applied on top of MySQL. MariaDB includes features which are similar to the corresponding features in MySQL, but the implementations differ, like for example the thread pool, microsecond support and query annotations in RBR binlog. MariaDB also includes a lot of features that are not in MySQL. For a complete listing of feature differences check out

To call the next MariaDB version MariaDB 5.6 would be misleading.

Eventually there will be a version of MariaDB which includes all the features of MySQL 5.6 either ported or implemented in a different way, but before that there will be at least a couple of releases which include some features which have been ported from MySQL 5.6 and some completely new features that aren’t in MySQL 5.6.

A concern we have received is that tools and other clients validating the server version they are connecting to might become incompatible with MariaDB without changes in the tool/client. Thank you Peter Laursen from Webyog for your input on this! The issue is that tools and other clients rely on the return statement of “SELECT VERSION();”. Based on what version number is returned the tool enables / disables features. The fact is that no version numbering can solve it. Even if we would call our next release 5.6.1, it would not have all the features of MySQL 5.6.1, only some of them. It would also have some of the features of later MySQL releases, and features that are not in MySQL at all. In other words no single MySQL version number can adequately describe the feature set  of MariaDB. Thus we think it will be less confusing and less ambiguous to use a completely different number, a distinct version series.

We suggest that “SELECT VERSION();” return the correct version, e.g. 10.0.1-MariaDB.

In addition to the reasoning above current MariaDB releases already introduce additional functionality for tools — like more statistics and extra switches — compared to MySQL. This added functionality is highly beneficial for tools to take advantage of. We highly recommend tool vendors to separate between MySQL and MariaDB in this regard today, and doing so will only become more important going forward. We are also thinking about introducing a way for DBAs to impact what the VERSION() string says.

One area that seems to rule out all fancier version numbering, like 5.5-10.0, is the distribution packages, which in general support only normal versioning of type major.minor[.build[.revision]]. Even if a specific package format would support some more complex version number scheme the upgrade determination becomes hard if the introduced new version number is not only incremented numbers.

I hope this explains the logic behind choosing 10 to be the version number of the next MariaDB version. Your feedback on this is still however still more than welcome.

It is not a secret that we’ve been kicking the tires and playing with JIRA for project management. After using it since the beginning of the year most of us like the feel of it and we’ve decided that it makes sense to start using it more.

As you know, the MariaDB project has many fragmented resources. We report bugs in Launchpad. We store our plans in worklog. We’ve never used the Launchpad Blueprint feature for this very reason. We don’t use Launchpad Answers because we have the Knowledgebase.

With this move to hosted JIRA (yes, this is an important link: we can report bugs, have future plans, and also give users a roadmap which is pretty cool. One nifty feature is that in the past two releases, we had a roadmap and we didn’t slip in terms of a schedule. We had on time releases and that’s awesome!

So what does this mean for you? To report bugs, you will now do so on JIRA. To make feature requests and talk about our future plans, you will also now use JIRA.

We plan to deprecate Worklog and Launchpad bugs by 30 June 2012. Launchpad will however continue to host the source code for MariaDB.

What will happen to bugs already reported on Launchpad? We have migration scripts ready for this and when we press the button bug reports will nicely migrate over to JIRA. After that is done we’ll place a notification on the MariaDB bugs page in Launchpad about reporting new bugs in JIRA.

What will happen to feature requests and ideas already in worklog? Worklog will be put into a read-only mode and there will be notifications about the move to JIRA. Whenever needed we’ll copy & paste worklog items into JIRA.

What does it mean to the openness of the MariaDB project? It’s not affected at all. The MariaDB project will remain an open community friendly project and as a bonus it will be easier to follow what is going on in the project since you don’t have to jump between several tools to get the complete picture.

The consolidation to JIRA provides the means to report and track project status easier than before, which allows the MariaDB team, community members and other to better coordinate and prioritize work.

As a side note, JIRA (and other software by Atlassian) has sometimes been criticized in the open source world because of its commercial nature and many are unaware of the fact that Atlassian do offer a free Open Source Project License to open source projects, which is what is being used with MariaDB.

As another side note, I’m not going to dive into comparing features in e.g. Launchpad with features in JIRA. I do know it would be possible to use blueprints for feature specifications etc. in Launchpad. The most important aspect in my mind is that you pick a tool that you like the feel of, has the features you need and tightens collaboration between developers, project managers, community members and other persons involved in the project.

In short, this is all about three project tools becoming one.