Congratulations to Monty Program and the many community contributors for releasing the GA version of MariaDB 5.3. We were in our annual all-staff meeting last week, so we are a little slow to blog about this and acknowledge the great work that has gone into MariaDB. Better late than never, I hope.

Before I discuss some of the improvements in MariaDB 5.3, let me mention a few things briefly. First, Peter and Ovais are doing a lot of benchmarking of specific MariaDB 5.3 and MySQL 5.6 optimizer improvements, and both of them look very good indeed. Peter will present the results in an “optimizer standoff” talk at the upcoming MySQL conference, and Timour and Sergei from Monty Program will present a tutorial on a similar topic. Make sure you don’t miss this conference! Secondly, remember that our support contracts cover MariaDB as a first-class member of the MySQL family of databases. Finally, High Performance MySQL, Third Edition mentions MariaDB in many places, so you can learn more about where its features might be helpful to you.

So what’s new and great in MariaDB as compared to MySQL? A lot of things. Here are some of the highlights:

  • Pluggable authentication so you can integrate MariaDB with external auth systems
  • Dynamic columns and virtual columns (they’re different) offer flexibility in schemas
  • Microsecond time resolution for DATETIME and similar time-based types, as well as microseconds in SHOW PROCESSLIST
  • Group commit for the binary log makes the server much faster with the binary log enabled
  • Faster queries through speedier joins, faster subqueries, and elimination of useless tables in joins
  • Thread pooling and a segmented key cache for improved scalability

That’s really just a sampling. A good starting point for learning more is the MySQL versus MariaDB wiki page. Note that a lot of these features are also available either in Percona Server or in the upcoming MySQL 5.6 in the same or slightly different forms, so there is some subtlety to this list. For example, Percona Server has the same group commit fix, and MySQL 5.6 offers microsecond timestamp support, as well as a lot of optimizer improvements. Even the standard MySQL 5.5 offers pluggable authentication; you just have to pay for the plugin if you want the official Oracle one; or you can use Percona’s PAM plugin.

MariaDB 5.3 isn’t the only exciting thing, however. MariaDB 5.3 is based on MySQL 5.1, but MariaDB 5.5 will be based on MySQL 5.5, so it will inherit a lot of the great improvements Oracle has made to the MySQL 5.5 release. This should help MariaDB be faster and more scalable, as well as adding a lot of nice features like less lock contention, better diagnostics, improvements to partitioning, and the addition of multiple InnoDB buffer pools. Best of all, MariaDB 5.5 might be here pretty soon — I caught this mention on the MariaDB IRC channel:

There are strong forces to ensure 5.5 GA before percona live in Santa Clare

This is great news indeed.

MariaDB really has come a long way. I remember that a couple years back I told Monty, “fix subqueries and you will change the world for a lot of MySQL users.” Well, that dream has come true, and now we have subqueries that execute inside-out, as a sane user expects them to do.

The new MariaDB release is a great development for MySQL users. Users now have more choice than ever — there are three great versions of MySQL that suit different needs and personalities, with different characteristics, and feature and performance improvements are moving rapidly forward for the MySQL world as a whole.

17 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Twirrim

I’m looking forward to testing MariaDB with a particular use case that MySQL is struggling with (lots and lots of queries need rewriting to favour MySQL.)
I do seem to recall MySQL finally got around to fixing that microseconds bug recently.

pcdinh

I hope that the next MariaDB will have lof of improvements over GIS features. Geolocation is increasingly becoming one of the most important features for mobile-enabled services. Unfortunately, most of current services are still powered by PostgreSQL and PostGIS

William Jimenez

Great to see more development activity for this project. How do you feel MariaDB differs from Percona Server (or does it at all)?

Henrik Ingo

Don’t forget that Timour and Sergei are giving a 3 hour tutorial on MariaDB 5.3 (and 5.5?) and MySQL 5.6 optimizers: https://www.percona.com/live/mysql-conference-2012/sessions/improving-mysqlmariadb-query-performance-through-optimizer-tuning

Henrik Ingo

Baron: On MariaDB vs Percona server, I sometimes see MariaDB having a group consisting of rather ignorant users. This is not supposed to say anything negative of MariaDB or its developers, or even the entire userbase as a whole, but just an observation of a type that I sometimes see and always surprises me. The archetype of this ignorant group is something like:

* MariaDB is the new MySQL
* Oracle’s MySQL is completely closed source or at least will be very soon
* Has never heard of Percona Server

It is possibly a European thing, and obviously such a person would not be reading your blog or planet mysql. (So you can’t do much to educate them either 🙂

It would indeed be great to counteract such confusion with highlighting the real strengths of MariaDB.

Jan Steinman

When will 5.3 be on github?

When I do “brew install mariadb” it installs 5.2.8. When I do “brew update mariadb” it claims I have the latest.

My main motivation for exploring mariadb is to use the OQGRAPH engine, which apparently is included with 5.3 but not 5.2.8.

Thanks!

Twirrim

On the subject of “Oracle has killed MySQL and made it closed-source”, whilst they haven’t made it closed-source, what they do appear to have done is shift a lot of bugs into their private tracker. Mark Callaghan noticed the change around this time last year: http://mysqlha.blogspot.com/2011/02/where-have-bugs-gone.html and it’s not improved since. With private tracking numbers and CVEs of increasing in vagueness, it’s harder for people to back-port patches.

As an alternative Ubuntu has decided to just keep rolling out the latest version of MySQL for the moment and look to the possibility of switching to MariaDB (who keeps the whole process public) instead for the longer run. Upgrading to the latest version of MySQL is fine from a general perspective, but Oracle (and Sun before them) don’t just patch security exploits between releases, there are other things that get changed that might have unforeseen consequences (one of the reasons why distributions like to pin release versions.)
Given MariaDB is MySQL with patches, I’m not sure quite how much that gains, or if MariaDB are basically doing that work and making it clear what is and what isn’t security fixes. I should spend a bit more time looking at MariaDB one of these days!

Henrik Ingo

Jan: The real MariaDB repository is on Launchpad at lp:maria. The git repository you mention must be a copy maintained by a 3rd party.

Twirrim: Actually the Ubuntu discussion is one example of what I mentioned, though not totally as ignorant as my “archetype” above. It is interesting to note that before I pointed out that Percona Server even exists, it had not meen mentioned at all in the email thread where that was discussed. This is an observation that interests me, since it is completely different from what the core MySQL community focuses on – in fact I would say MariaDB is seriously underrepresented on places like planet mysql. (Ie possibly real MariaDB usage must be higher than what you’d believe from simply reading the blog posts on planet mysql)

FWIW, MariaDB may very well be a good choice for Ubuntu and Debian, at least when there is a 5.5 version. It’s just that for someone who actively works on all things MySQL every day, it was weird to see a discussion where people are not even aware of the existence of Percona. It didn’t look like a very enlightened discussion. (But yeah, they weren’t saying Oracle is closing MySQL source code.)

Personally I don’t see the problem distros have with the MySQL model. Contrary to common belief MySQL maintenance releases have never included new features as long as I have been involved – it is 100% bug fixes only. Possibly it is the case that distros would only want to patch security issues whereas MySQL also fixes non-security bugs like server crash, wrong result or just performance regressions. From my point of view the distros insisting on sticking to the original version they released and cherry pick patches on top of that might be worth questioning.

Twirrim

Unfortunately that’s not true Henrik. Take for example the InnoDB plugin that has changed frequently throughout a release.

http://www.chriscalender.com/?p=479

You can see that even within MySQL 5.5 GA we’ve gone from InnoDB plugin version 1.1.4->1.1.8.

Also, take a look at the changes in 5.5 from here: http://dev.mysql.com/doc/refman/5.5/en/news.html. Quite a number of them have a “Functionality Added or Changed” section (e.g. 5.5.18, 5.5.17, 5.5.16, 5.5.14). Whilst the majority of them aren’t significant or liable to have any real impact on people, some of them are. For example from 5.5.10: http://dev.mysql.com/doc/refman/5.5/en/news-5-5-10.html

“Incompatible Change: The shared library version of the client library was increased to 18 to reflect ABI changes, and avoid compatibility problems with the client library in MySQL 5.1. Note that this is an incompatible change between 5.5.10 and earlier 5.5 versions, so client programs that use the 5.5 client library should be recompiled against the 5.5.10 client library. (Bug #60061, Bug #11827366)”

With Linux distributions like Debian or RedHat, a number of the compiled versions of various programs will have been complied against what comes at release, and would have been potentially broken by this unless everything had been re-compiled and pushed out to the repositories at the same time.

Henrik Ingo

Twirrim: But the incompatible change in the client library could still be due to a bug that needed to be fixed. I doubt they mess with it just for fun. But yes, I certainly see why these kind of changes in the library are a showstopper for linux distributions.

Jan Steinman

Henrik, sorry for the confusion — much of it on my part!

The github build I was referring to is for package installation on MacOS using the “homebrew” package installer, since there is no official binary installation.

I’ve updated the “brew” package to refer to 5.3.5-ga and included instructions for installing the OQGRAPH engine, which is not installed by default, as it requires the “boost” library. (Whew! And I thought I had nothing better to do on a nice sunny day… 🙂

I now have a 5.3.5-ga server and client on Mac OS 10.6.8 that are talking to each other, that claims OQGRAPH is installed. Haven’t really done any tests yet…

Olivier

Henrik, I’m now a user of MariaDB and here are my reasons :
– Oracle is known for killing others softwares. They may not have killed MySQL completely at the moment, but it will happen someday in a way or another… Like said by others people in the comments : what is this private bug tracker things ? Don’t you think it’s weird to have an open source software and hide bugs like that ?
– I could have used Percona Server because it seems great. But there’s a big “feature” missing for me : there’s no Windows version. Sure, our production servers are under Linux, but our develoment computers are under Windows and I prefer to use MariaDB under Windows and Linux than different softwares on different platforms.

Henrik Ingo

Olivier: The Windows support is possibly the most important feature of MariaDB. I’m really glad we got it going early on (I was employed there then). At least in 2010, over half of MariaDB downloads was for the Windows version.

Regarding Oracle, you’re right, I’m not the big optimist on that front either (like Baron and others are). But MySQL is not closed source, and even the closed source modules Oracle recently published are nothing more than what could have been expected from MySQL AB itself – they always shipped some closed stuff. The bug tracker otoh is clearly an Oracle thing, we expected it to happen (InnoDB bugs were never public) and unfortunately it did happen.

Henrik Ingo

That is fair, and perhaps what sets you apart from others is that you remember to do it more often than many of us. Which is also true for MariaDB, as this blog post shows. (I intend to write one too, but I’m even more late than you…)

It may have got lost, but that was also my original point: MySQL is not closed source (any more than it has been for years) and it hasn’t been killed. Other than that, there are also some good reasons to use MariaDB.