The MariaDB project is pleased to announce the immediate availability of MariaDB Galera Cluster 10.0.17 and MariaDB Galera Cluster 5.5.42. Both are Stable (GA) releases.

Download MariaDB Galera Cluster 10.0.17

Release Notes Changelog What is MariaDB Galera Cluster?

Download MariaDB Galera Cluster 5.5.42

Release Notes Changelog What is MariaDB Galera Cluster?

MariaDB APT and YUM Repository Configuration Generator

See the Release Notes and Changelogs for detailed information on these releases.

Thanks, and enjoy MariaDB!

Year 2014 was an important year for the MariaDB project with the release of MariaDB 10.0. Adoption continued to grow both organically and by MariaDB being included both in the Red Hat Enterprise Linux and Suse Linux Enterprise Server distributions as the default database option. Ubuntu started providing MariaDB as an option since their release 14.04. MariaDB also came available in many cloud services, e.g. DBaaS in the Rackspace Cloud and Cloud Foundry. Those are just a few highlights. There is of course a lot of other news from last year which has already been covered earlier.

If you’re interested in what the MariaDB Foundation worked on last year, Monty wrote a wrap-up on it. You can find it here.

In this article I want to focus on a few recent changes related to the MariaDB Foundation. On Monday this week, the MariaDB Foundation had its first board meeting of the year. In addition to all the general things on a board meeting agenda there were the following topics:

  • New memberships
  • Approval of new board member
  • Approval of new CEO

A Norwegian company called Visma has become a member of the MariaDB Foundation. Visma is a 6,000 person software company focused on finance and accounting software and services.

As part of Visma becoming a member it was also suggested that Visma gets a representative on the board. It would be hard to find a more suitable person for the job than Espen Håkonsen, CIO of Visma and Managing Director of Visma IT & Communications.

The MariaDB Foundation has been looking for a new CEO since Simon Phipps left last fall. Late last year discussions started with Otto Kekäläinen and he got interested. Otto is an entrepreneur in the open source business in Finland. He is the CEO of the open source consulting company Seravo. In addition he has several important open source roles in Finland and Europe. Otto is Finland’s representative in the Free Software Foundation Europe and in the steering group of COSS, the Finnish Centre for Open Systems and Solutions, the umbrella open source association in Finland. Otto will also serve as the Secretary of the board.

These changes in the board and management of the MariaDB Foundation were approved in the board meeting. I’m delighted to have Espen and Otto to join the MariaDB Foundation. They bring a lot of new experience and ideas to the foundation. Welcome!

Chairman of the board
Rasmus Johansson



For the moment, the only engines that fully support encryption are XtraDB and InnoDB. The Aria storage engine also supports encryption, but only for temporary tables.

MariaDB supports 2 different way to encrypt data in InnoDB/XtraDB:

  1. Specified table encryption: Only tables which you create with PAGE_ENCRYPTION=1 are encrypted. This feature was created by eperi.
  2. Tablespace encryption: Everything is encrypted (including log files). This feature was created by Google and is based on their MySQL branch.

InnoDB Specified Table Encryption

Specified Table encryption means that you choose which tables to encrypt. This allows you to balance security with speed. To use table encryption, you have to:

  • Set the value of encryption-algorithm to the algorithm of your choice.
  • Load the file-key-management-plugin (or similar)
  • Define the location of key file
  • Create keys


Keys can be generated using OpenSSL with following command

The key file is a text file containing an key id, the hex-encoded iv and the hex-encoded key. Example keys.txt using above generated key:

After this is it up to database designer to select tables that contain sensitive data for encryption. Encryption can be enabled to table in table creation time or using ALTER TABLE. As an example:

In table encryption currently keys can’t be changed but used key can be changed using ALTER TABLE. If no key identifier is provided a default key is used. Default key can be set either on my.cnf with

or dynamically using global setting:

Default key is used e.g.

InnoDB Tablespace Encryption

In tablespace encryption all InnoDB tables are encrypted. Additionally, you may encrypt InnoDB log files, Aria tables (ROW_FORMAT=PAGE) and Aria temporary tables. To use tablespace encryption, you have to:

  •  Set the value of encryption-algorithm to the algorithm of your choice.
  • Load the example-key-management-plugin (or similar)


In tablespace encryption keys are not static. Instead so called key rotation is used. In key rotation used encryption key is changed if key used on a page is older than innodb-encryption-rotate-key-age seconds.

InnoDB Tablespace Scrubbing

Scrubbing means that there is a background process that regularly scans through all tables and upgrades the encryption keys for the pages. This happens either as part of purge (non compressed) or scrubbing by scanning whole tablespaces (added into key rotation threads). Purge is a a type of garbage collection that InnoDB internally runs to improve performance. Configuration for this feature might look as follows:

Performance Impact

Encrypting the tables or tablespaces naturally have some effect on overall performance of the system. Naturally, the amount of performance effect encryption has is dependent on used hardware, workload and used encryption method. Goal of this section is to give some indication how much effect on performance there is when table encryption is used or when tablespace encryption is used when compared to setup where no encryption is used.

All experiments where conducted on Intel Xeon E5-2690 @ 2.9GHz CPU containing 2 sockets with 8 cores each using hyper threading, thus 32 total cores and Linux 3.4.12 with 132G main memory. The database is stored on a Fusion-io ioDrive2 Duo 2.41TB Firmware v7.2.5, rev 110646, Driver 3.3.4 build 5833069. The database filesystem is using NVMFS and all test logs and outputs are stored on second ioDrive using EXT4. We use On-Line Transaction Processing (OLTP) benchmark from Percona This TPC-C like workload involves a mix of five concurrent transaction types executed on-line or queued for deferred execution. The database is comprised of nine tables with a wide range of record and population sizes. Results are measured in terms of transactions per minute (tpmC). We will use 1000 warehouses producing ~100G database and buffer pool size 50G, so that full database does not fit to buffer pool. Additionally, we will use only InnoDB plugin as a storage engine. Finally, we use 3 hour measure time.

In the first graph we compare the resulting tpmC results on normal InnoDB tables (unencrypted tables), page encrypted tables, using passive key rotation and scrubbing (setting both intervals bigger than test time) and tablespace encryption (google full encrypted on graph).



MariaDB Corporation would like to thank eperi and Google for their contributions to MariaDB.