Ensuring continuity and open collaboration

MariaDB 10.1 is stable GA

With the release of 10.1.8, MariaDB takes a next step. MariaDB 10.1 is now considered a stable release.

MariaDB 10.1 has a couple of main themes:

  • Security
  • High Availability
  • Scalability

During the last few years there have been many request for more security features in MariaDB. Actually it’s a trend in general. Since open source software is getting more attractive all the time, more functionality is wanted in areas where proprietary software typically has been leading. This is especially true for databases. In addition data privacy is a very hot topic.

The big new thing in security for MariaDB 10.1 is a complete data at rest encryption solution. The encryption that now is in use originates from Google’s encryption patch. It has now been migrated into MariaDB 10.1. The solution is fairly advanced, encrypting the actual data files on disk of course, but also all other places where data touches disk like the binlog in replication. It also introduces the concept of rolling encryption keys, where keys can be set to expire at some certain intervals causing data to be re-encrypted with new keys and becoming inaccessible with the old keys.

In addition to encryption, 10.1 also includes other security aspects like password validation with which one can define a scheme, for example with the popular cracklib library, against which new passwords are validated.

On the High Availability front there is a significant change. In 5.5 and 10.0 there are separate versions of MariaDB and MariaDB Galera Cluster. In 10.1 this has changed. There is only one MariaDB 10.1. It includes the cluster capabilities and they can just be switched on whenever needed.

In regards of scalability there are multiple aspects. On one hand the parallel slave replication introduced in MariaDB 10.0 is now further improved into what is called optimistic parallel replication. Very much simplified, this means that any INSERT/UPDATE/DELETE can be applied in parallel on the slave (even it wasn’t on the master) which in most cases will result in a performance gain.

When it comes to replication there is another very important compatibility aspect added to 10.1. MariaDB can now be a slave to MySQL 5.6 (or greater) also when MySQL 5.6 is configured to use GTID. This has been a highly voted feature request since users wants to be able to test MariaDB as part of their MySQL deployment. When migrating to MariaDB this functionality is also essential.

Another important aspect of scalability is that 10.1 includes a lot of performance improvements to perform better on CPUs with more processing power and more cores. Also on the disk IO side there are several improvements like page compression and defragmentation. Defragmentation is based on the patch developed first by Facebook and then further developed by Kakao Corp.

There are a lot of other new capabilities and improvements in MariaDB 10.1, like supporting new spatial reference systems and outputting explains in JSON. To get a complete list of new functionality please refer to the “What is MariaDB 10.1?” page.

Most important of all, go download MariaDB 10.1.8, install it, and start putting your workloads on it. Stay in contact with us by filing any findings that you think are wrong in Jira. You can also reach the developers of MariaDB on the #maria channel on Freenode IRC or email the developers by joining the mailing list maria-developers. Do enjoy!

Leave a Reply

Your email address will not be published. Required fields are marked *

Sponsors

MariaDB Foundation sponsors

Tweets by @mariadbfdn

Code statistics