The MariaDB developers have made several releases in the past week. Rather than post about all of them separately, we decided to combine them into one post. Details for each release are available on their individual Release Notes and Changelog pages.

MariaDB 5.5.36

First up is MariaDB 5.5.36. This is a Stable (GA) release. Apart from general maintenance, bug fixes, and updates, TokuDB is now included in RPM packages for CentOS 6 on x86-64.

Download MariaDB 5.5.36

Release Notes Changelog What is MariaDB 5.5?


MariaDB Galera Cluster 10.0.7

Next is MariaDB Galera Cluster 10.0.7. This is an Alpha release. It is being released now to get it into the hands of any who might want to test it. Do not run Alpha releases on production systems! This version of MariaDB Galera Cluster supports wsrep API v25 which means MariaDB Galera Cluster can be used with either a 25.2.x or 25.3.x Galera wsrep provider. A 25.3.x wsrep provider is included in the MariaDB repositories. And both 25.3.x and 25.2.x wsrep providers are available on the downloads page.

Download MariaDB Galera Cluster 10.0.7

Release Notes Changelog What is MariaDB Galera Cluster?


MariaDB Java Client 1.1.6

The last release in the roundup is MariaDB Java Client 1.1.6. This is a Stable (GA) release. Several bugs were fixed and a new connection parameter, serverTimezone, was added. If set, timezone conversions will occur when storing temporal data with preparedStatement and when reading data using ResultSet. The effect is similar to setting the time_zone session variable. The difference is better cross-platform compatibility (i.e timezone names like “Asia/Omsk” can also be used when the server is on Windows). Also, this option works for both datetime and timestamp datatypes, while the server-side option has no effect on datetime.

Download Java Client 1.1.6

Release Notes Changelog Java Client Overview


Thanks, and enjoy MariaDB!

I’m happy to announce that a new version of the MariaDB Audit Plugin is available. Version 1.1.5 can be downloaded here. As you can see the Audit Plugin is available from SkySQL, who has developed the plugin.

However, now with the Audit Plugin being GA for a couple of months since 7th of November last year and customers using it in production, SkySQL has decided to contribute the Audit Plugin to the MariaDB project and I’m happy to tell you that starting from MariaDB versions 5.5.37 and 10.0.9 the Audit Plugin will be included by default. Notice that these versions of MariaDB aren’t yet released.

The MariaDB Audit Plugin introduces the capabilities of tracking user access to data. By having the Audit Plugin available by default in MariaDB, all users can easily set up tracking in their own systems and follow in real time who’s doing what in their databases. In addition to having the Audit Plugin available in MariaDB it’s also available for download, which is very useful for MySQL and Percona Server users. Yes, the MariaDB Audit Plugin has been tested on MySQL and Percona Server as well.

The development on the Audit Plugin, stretching from specification work to real-world testing has been done together with customers who knew exactly what they needed in terms of auditing. Since then there is a growing amount of users of the Audit Plugin. It seems to be useful for a lot of users.

For additional and very practical how-to type of information I would recommend reading the following articles:

There is also a webinar available by Ralf Gebhardt on the topic:

Lets start by considering a scenario where records are being inserted in a single auto-increment table via different nodes of a multi-master cluster. One issue that might arise is ‘collision’ of generated auto-increment values on different nodes, which is precisely the subject of this article.

As the cluster is multi-master, it allows writes on all master nodes. As a result of which a table might get same auto-incremented values on different nodes on INSERTs. This issue is discovered only after the writeset is replicated and that’s a problem!

Galera cluster suffers with the similar problem.

Lets try to emulate this on a 2-node Galera cluster :

As expected, the second commit could not succeed because of the collision.

So, how do we handle this issue? Enter @@auto_increment_increment and @@auto_increment_offset! Using these two system variables one can control the sequence of auto-generated values on a MySQL/MariaDB server. The trick is to set them in such a way that every node in the cluster generates a sequence of non-colliding numbers.

For instance, lets discuss this for a 3-node cluster (n=3):

As you can see, by setting each node’s auto_increment_increment to the total number of nodes (n) in the cluster and auto_increment_offset to a number between [1,n], we can assure that auto-increment values, thus generated, would be unique across the cluster, thus, would avoid any conflict or collision.

In Galera cluster this is already taken care of by default. As and when a node joins the cluster, the two auto-increment variables are adjusted automatically to avoid collision. However, this capability can be controlled by using wsrep_auto_increment_control variable.

With this setting the last COMMIT in the above example would succeed.