Posts Tagged ‘MariaDB’

MariaDB turns 5!

I stopped working on MySQL at Sun Microsystems in late 2009 (after a lengthy period of garden leave), to join Monty Program Ab, and was greatly anticipating a MariaDB release that we could take to market. The first GA release of MariaDB came out February 1 2010 – MariaDB 5.1.42. Today is MariaDB Server’s 5th birthday!

We didn’t even want to call it GA back then — we referred to it as a “stable” release. We didn’t make our own builds because we figured source code tarballs were good enough; so builds were made and hosted at OurDelta. It took some months (around August 2010) when we moved release notes to the Knowledgebase (which you’ll notice has moved from to its current location) from the old front page wiki install that we had at

I didn’t go to the first company meeting in Malaga due to having the chickenpox, so my first meeting was the one we did in Reykjavik, Iceland. We did it towards the end of February 2010, and planned it literally in a month – maybe a celebration that we brought 5.1 to market on time, and also to plan 5.2.

Speaking of companies, we were Monty Program Ab (professionally this quickly became MariaDB Services Ab), then SkySQL Ab (via merger), and finally MariaDB Corporation Ab (via re-branding). Shortly before the SkySQL Ab merger, we even have the MariaDB Foundation appear.

Anyway, what have we released? MariaDB 5.1, MariaDB 5.2, MariaDB 5.3, MariaDB 5.5, MariaDB 10.0, MariaDB Galera Cluster 5.5 & 10.0, a special MariaDB 5.5 with TokuDB build and a special MariaDB with FusionIO improvements build. To boot, we also have three client libraries (connectors, if you must): C, Java, and ODBC.

So 5 major server releases (7 if you count the Galera series), and we’re now working on MariaDB 10.1. I count 88 releases of the server across various versions (with breakdowns: 9 alphas, 11 betas, 7 release candidates and 61 GAs). We’ve had 23 Galera releases and 15 releases for the various client libraries.

We are shipping in all major Linux and BSD distributions. In many, we are even the default

This birthday is a nice time to look back at our achievements, but also to remind ourselves to not rest on our laurels and continue to focus on growth. The last sanctioned press release talks of over 2 million users globally. 

Thank you to all our users. Thank you to all the contributors and developers. Here’s to a lot more adoption, growth, releases and technology improvements!

osquery is neat

Facebook recently made opensource, osquery. It gives you operating system data via SQL queries! Its very neat, and you can test this even on MacOSX (it works on that platform & Linux). It is by far the project with the most advanced functionality, linked here in this post.

I noticed that rather quickly, there was a PostgreSQL project, called pgosquery, based on Foreign Data Wrappers with a similar idea. (apparently it was written in less than 15 minutes; so a much lower learning curve than the regular MySQL storage engine interface)

I immediately thought about an older MySQL project, by Chip Turner (then at Google, now at Facebook), called mysql-filesystem-engine. This idea was kicking around in 2008. I was intrigued by hearing about this at a talk (probably at the MySQL Conference & Expo); it’s a pity no one took this further.

On a similar tangent, did you also know that there is the option to use MySQL as storage via FUSE (see: mysqlfs)? An article by Ben Martin shows some practical examples.

At its heyday, MySQL had many storage engines (maybe around 50). Wikipedia has an incomplete list. I see some engines on that list, and think that some of these folk are also creating MongoDB backends — competition. At MariaDB we are probably shipping the most storage engines of any MySQL-based distribution, however I think we could be doing an even better job at working with upstream vendors, and figuring out how to support & augment business around it.

RHEL7 now with MariaDB

Congratulations to the entire team at Red Hat, for the release of Red Hat Enterprise Linux 7 (RHEL7). The release notes have something important, under Web Servers & Services:

MariaDB 5.5

MariaDB is the default implementation of MySQL in Red Hat Enterprise Linux 7. MariaDB is a community-developed fork of the MySQL database project, and provides a replacement for MySQL. MariaDB preserves API and ABI compatibility with MySQL and adds several new features; for example, a non-blocking client API library, the Aria and XtraDB storage engines with enhanced performance, better server status variables, and enhanced replication.

Detailed information about MariaDB can be found at

This is a huge improvement over MySQL 5.1.73 currently shipping in RHEL6. I’m really looking forward to welcome more MariaDB users. Remember if you are looking for information, find it at the Knowledge Base. If you’ve found a bug, report it at Jira (upstream) or Bugzilla (Red Hat). If you want to chat with friendly developers and users, hop on over to #maria on And don’t forget we have some populated mailing lists: maria-discuss and maria-developers.

MariaDB 10 – XtraDB & InnoDB versions

I’ve had this question several times when presenting and once via an internal email thread so I figure I might as well write about it: What is the default transactional engine in MariaDB 10.0? The answer is simple – it is XtraDB.

However this answer has some history: initial releases of MariaDB 10 actually shipped with InnoDB from MySQL 5.6. Only in 10.0.9 RC did the default switch back to being XtraDB. As MariaDB users previously know, XtraDB was the default InnoDB in 5.1, 5.2, 5.3, and 5.5 too. As always, you can switch easily between InnoDB/XtraDB – read more in: Using InnoDB instead of XtraDB

How do you tell what version of InnoDB or XtraDB you are running? Simply, run: SHOW GLOBAL VARIABLES LIKE 'innodb_version';

MariaDB 10.0 (read more: What is MariaDB 10.0):

Version InnoDB XtraDB Status Date
10.0.10 5.6.15 5.6.15-63.0 * GA 31 Mar 2014
10.0.9 5.6.15 5.6.15-63.0 * RC 10 Mar 2014
10.0.8 5.6.14 * 5.6.14-62.0 RC 10 Feb 2014
10.0.7 5.6.10 * 5.6.14-62.0  Beta 27 Dec 2013
10.0.6 1.2.6 * n/a Beta 18 Nov 2013
10.0.5 1.2.5 * n/a Beta 7 Nov 2013
10.0.4 1.2.4 * (5.6.10 merge) n/a Alpha 16 Aug 2013
10.0.3 10.0.3-MariaDB * n/a Alpha 11 Jun 2013
10.0.2 10.0.2-MariaDB * n/a Alpha 24 Apr 2013
10.0.1 1.2.1 *  n/a Alpha 6 Feb 2013
10.0.0 1.2.0 (5.6.5 merge) n/a Alpha 12 Nov 2012

The asterisk (*) denotes the default engine choice.

Why are there odd InnoDB versions from 10.0.0 – 10.0.6? I can only point this to merge oddities. storage/innobase/include/univ.i is the file which contains common definitions such as INNODB_VERSION_MAJOR, INNODB_VERSION_MINOR and INNODB_VERSION_BUGFIX. INNODB_VERSION_BUGFIX in 10.0.6 pointed to MYSQL_VERSION_PATCH which you get from the VERSION file. For XtraDB, you will also see PERCONA_INNODB_VERSION in univ.i.

So, when XtraDB is the default (10.0.9 and 10.0.10 and releases going forward) you can put in my.cnf to load InnoDB:


When InnoDB is the default (10.0.8 and 10.0.7) and XtraDB was merged, you can put in my.cnf to load XtraDB:


Percona Server only became GA with 5.6.13-61.0 which was 7 Oct 2013 which explains why the MariaDB 10.0.6 beta didn’t include a XtraDB.

Percona Server only ships XtraDB (source code in storage/innobase) while MariaDB ships both InnoDB (storage/innobase) as well as XtraDB (storage/xtradb).

If you want older release information about InnoDB plugin versions, a great resource is Chris Calendar’s blog post: InnoDB Plugin Versions. I’m just glad that going forward the InnoDB version will just match the release version as you can see with 10.0.7 and later.

MySQL 5.6 + GTID & MariaDB 10 replication

While at the keynote of Tomas Ulin at Percona Live MySQL Conference & Expo Santa Clara 2014, he asked the audience what they were running, and most of the audience was on MySQL 5.5 while about 15% of the audience was on MySQL 5.6. This number is steadily increasing I’m sure, so one thing that becomes important is that people will probably start turning on Global Transaction Identifiers (GTIDs). 

As you may already know, MariaDB 10 has a different implementation of Global Transaction ID. To me, this poses a problem in a mixed use environment (or even a migration scenario). Which is why MDEV-4487 is so important: it is a feature request to allow replication from MySQL 5.6+ when GTID is enabled on the master

If you think the issue is important, you can vote and watch the issue on JIRA. I for one think this should be fixed for 10.0.11 or 10.0.12 and not wait for the 10.1 timeframe. Best not to comment here, focus on the JIRA request, MDEV-4487.

MySQL related IRC discussion channels

There are many MySQL related IRC discussion channels as the ecosystem itself grows. I join the following. Are there any that I’m missing?

Freenode (

  • #mysql – main channel for all kinds of end user MySQL related discussions (the noisiest of the lot, naturally)
  • #maria – main channel for all kinds of MariaDB related discussions
  • #webscalesql – for all kinds of WebScaleSQL discussions
  • #percona – main channel for all kinds of Percona related discussions
  • #tokutek – main channel for Tokutek discussions (TokuDB or TokuMX)
  • SkySQL-specific channels: #maxscale and #mariadb-mgr


  • #debian-mysql – for all kinds of Debian MySQL related bits (packaging, bugs, etc.)