About two and a half years ago I wrote about how the MariaDB project moved bug reporting from Launchpad to JIRA. Every now and then I get contacted about how it was done and whether I would be willing to share the tools used for doing it and of course I’ve done that. Especially in one occasion the scripts were even further developed by one company that was in the process of doing exactly the same, i.e. moving bugs from Launchpad to JIRA. Thanks for the enhancements Philip Colmer from Linaro!

In Launchpad there isn’t a readymade tool for exporting bugs and I didn’t find any 3rd party tools for doing it. Launchpad however has an API through which most (if not all) information in Launchpad can be retrieved. Launchpad has made a library available in Python making use of this API.

By using the Launchpad Python API, I wrote a Python script LaunchpadBugs.py that pulls out bug information from Launchpad and creates an XML document for each bug. If the bug includes attachments these are also downloaded and named in a way that they can be connected to the XML.

It would, of course, be nice if the bunch of XML files and attachments that you end up with after running the Python script could be uploaded directly into a JIRA instance. Unfortunately this is not possible, unless it has been added recently, and instead a separate format is needed. According to my investigations, JIRA supports importing information best if it’s in CSV (comma separated values) format. That leads to converting a bunch of XML files to a CSV file. The CSV file can include links to the attachments.

I’ve done quite a lot of C# programming in the past and still had the way of dealing with XML in C# in my head, so I chose to do the XML to CSV conversion in C# in a Windows command line application. You’ll find the application named JiraCSV in the Github repository mentioned below.

The scripts described above have been useful for those that have reached out explicitly asking for a copy of them, but maybe the interest is broader. To initially get to the point where migration was successful it took a lot of trials to correct the data, add missing data, change the XML or CSV structure, and so on to get everything accepted by JIRA. I hope that by now sharing these scripts people will save a significant amount of time. That’s why I’ve decided to put them up on Github so that anyone interested in them can pick them up and make use of them or even improve them further. You can find them at https://github.com/rasmushoj/LP2JIRA.

It’s been almost a year since I benchmarked MariaDB and MySQL on our good old 4 CPU / 32 Cores / 64 Threads Sandy Bridge server. There seem to be a few interesting things happened since that time.


  • MySQL 5.6.23 peak throughput dropped by ~8% compared to 5.6.14. Looks like this regression appeared in MySQL 5.6.21.
  • 10.0.18 (git snapshot) peak threads increased by ~20% compared to 10.0.9 and reached parity with 5.6.23 (not with 5.6.20 though).
  • 10.1.4 (git snapshot) and 5.7.5 are the champions (though 10.1.4 was usually 1-5% faster). Both have similar peaks @ 64 threads. They seem to be pushing this system limits, since both have capacity to scale more.
  • 5.7.6 has serious (~50%) scalability regression compared to 5.7.5. There is heavy LOCK_plugin mutex contention, which seem to be caused by query rewrite plugin framework. I couldn’t find way to disable it. Hope this will be fixed in coming releases.

Raw data available at google doc.


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 https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql. 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.