Colin Charles Agenda

I think one of the big announcements that came out from the Amazon Web Services world in October 2015 was the fact that you could spin up instances of MariaDB Server on it. You would get MariaDB Server 10.0.17. As of this writing, you are still getting that (the MySQL shipping then was 5.6.23, and today you can create a 5.6.27 instance, but there were no .24/.25/.26 releases). I’m hoping that there’s active work going on to make MariaDB Server 10.1 available ASAP on the platform.

Just last week you would have noticed that Amazon has rolled out MySQL 5.7.10. The in-place upgrades are not available yet, so updating is via dump/reload or using read replicas. According to the forums, a lot of people have been wanting to use the JSON functionality.

Are you trying MySQL 5.7 on RDS? How about your usage of MariaDB Server 10.0 on RDS? I’d be interested in feedback either as a comment here, or via email.

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):

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:

ignore_builtin_innodb
plugin_load=innodb=ha_innodb.so

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:

ignore_builtin_innodb
plugin_load=innodb=ha_xtradb.so

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.

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.

A few things to note recently, amongst MariaDB in distributions. 

1. Ubuntu keeps MySQL 5.5 despite MariaDB’s success. There’s a lot of reasons for this, but remember the key takeaway here is MySQL 5.5 & the fact that MariaDB wasn’t even in Debian yet when the decision was made.
2. MariaDB is now inside of Debian/sid – check out the packages.
3. RHEL 7 comes with MariaDB 5.5 as a default; this is a good thing.

Now, from a distribution standpoint, we’re looking at starting to ship 10.0 as well. Distro maintainers don’t want one-way streets (i.e. an upgrade to MariaDB prevents you from going back to MySQL). This is something we have to deal with as more start looking at MySQL 5.6 & MariaDB 10 (think temporal literals as an example).

In recent time, MariaDB 10 has been getting many new storage engines. We’ve seen TokuDB, CONNECT, SEQUENCE, SPIDER, CassandraSE for various use cases. For a long time, MariaDB shipped OQGRAPH, but it was disabled in MariaDB 5.5. It will make a come back as OQGRAPH v3 has been worked on actively by Andrew McDonnell. Keep track of this via MDEV-5319.

Another engine being worked on by Kentoku Shiba & team is the mroonga engine, which allows you to do full text search. It is optimised for CJK languages, and is supposedly very fast. To track this, follow MDEV-5222.

What this means is that from the start of the MariaDB project, the only engine that we have disabled and don’t include since 5.5 and greater is PBXT. That’s a pretty good record of having many shipping storage engines that have largely come from the community.

Since MariaDB aims to be a compatible/drop-in replacement to MySQL, its crucial that in 10.0 we support all the 5.6 options/system variables, else we have to clearly document them in the Knowledgebase article MariaDB versus MySQL – Compatibility.

To this extent, Sergey Vojtovich (svoj) has created MDEV-5277 as a tracker. There is also plenty of discussion on this topic at the maria-developers mailing list. I encourage current users of MySQL 5.6 to take a look at the list and comment either in Jira or on the mailing list to ensure that when we are ready for MariaDB 10.0, we cover what you’re using.