To help with these problems as well as provide a pastebin for MariaDB developers to share explains during development we created The MariaDB/MySQL Explain Analyzer. This tool:

1. Helps unmangle explains (both vertical and tabular format)
2. Displays explains in an easy-to-read format.
3. Highlights and provides explanations for some terms.
4. Links to KB articles for different optimization techniques.
5. (Optionally) Allows you to save the explain for sharing.

This is the first release so there are still improvements to make. If you have any suggestions, feature requests or bug reports please let us know.

For more information, please see this KB article.

MariaDB seals

Last year, when it became clear that O’Reilly wasn’t going to arrange the MySQL user conference in the future, there was a lot of discussion on who should arrange it. In the end Percona was pretty fast informing everyone that they had booked the convention center in Santa Clara to arrange the conference this year. Now with the results to hand it’s easy to say that the conference was very well arranged. Great work Percona!

The MariaDB booth was located in the .Org section of the expo hall and we experienced a huge crowd, especially on the first day (Wednesday) of the conference. Our t-shirts were really popular and we could probably have handed out even double the amount of what we had with us. Unfortunately for those in attendance, we had to put some aside for our next upcoming event in Bellingham, WA, USA 28-29th of April. It’s the LinuxFest Northwest 2012, http://linuxfestnorthwest.org. We hope to see some of you there!

We released MariaDB 5.5.23 GA on Tuesday of the conference. Apparently people just loved this news and we’ve enjoyed double our usual download rates since then.

On the SkySQL MariaDB Solutions Day on Friday the 13th, the MySQL founders Monty and David started the day with a panel and the day continued with sessions on all kinds of MariaDB and MySQL related topics. Make sure you read SkySQL’s summary, http://www.skysql.com/blogs/jenwilbur/seal-you-next-year-successful-mysql-friday-13th-santa-clara.
SkySQL has also posted pictures of the event on https://www.facebook.com/skysql.

Happy panelist Monty

During the conference we had many interesting conversations with people and businesses that we haven’t had a chance to meet before who had migrated to MariaDB. I’m certain there will be even more of these discussions this year and next.

To stay up to date with MariaDB, add yourself to the MariaDB announce list, which informs mainly about new releases. Also add yourself to the MariaDB Facebook page to get even more MariaDB news. Sign up at http://mariadb.org.

• MariaDB 5.5.23 Release Notes
• MariaDB 5.5.23 Changelog
• MariaDB 5.5.23 Downloads

Please see the What is MariaDB 5.5 page for an overview of MariaDB 5.5.

Sources, binaries, and package downloads are available from our network of MariaDB mirrors. Debian and Ubuntu packages are available from our mirrored apt repositories. We have a sources.list generator for creating sources.list entries.

Most importantly, MariaDB 5.3.6 includes a fix for a bug which, under certain rare circumstances, allowed a user to connect with an invalid password. This is a serious security issue. We recommend upgrading from older versions as soon as possible.

• MariaDB 5.3.6 Release Notes
• MariaDB 5.3.6 Changelog
• MariaDB 5.3.6 Downloads

Please see the What is MariaDB 5.3 page for an overview of MariaDB 5.3.

Sources, binaries, and package downloads are available from our network of MariaDB mirrors. Debian and Ubuntu packages are available from our mirrored apt repositories. We have a sources.list generator for creating sources.list entries.

Most importantly, MariaDB 5.1.62 and 5.2.12 include a fix for a bug that under certain rare circumstances allowed a user to connect with an invalid password. This is a serious security issue. We recommend upgrading from older versions as soon as possible.

Please see the What is MariaDB 5.1 page for an overview of MariaDB 5.1, and the What is MariaDB 5.2 page for an overview of MariaDB 5.2.

Sources, binaries, and package downloads are available from our network of MariaDB mirrors. Debian and Ubuntu packages are available from our mirrored apt repositories. We have a sources.list generator for creating sources.list entries.

We are pleased to announce the immediate availability of MariaDB 5.1.61 and MariaDB 5.2.11. Both of these stable (GA) releases incorporate MySQL 5.1.61 and several bug fixes.

Please see the What is MariaDB 5.1 page for an overview of MariaDB 5.1, and the What is MariaDB 5.2 page for an overview of MariaDB 5.2.

Sources, binaries, and package downloads are available from our network of MariaDB mirrors. Debian and Ubuntu packages are available from our mirrored apt repositories. We have created a sources.list generator for creating sources.list entries.

MariaDB 5.5 is a merge of MariaDB 5.3 and MySQL 5.5 with some limited additional bug fixes. Please see the What is MariaDB 5.5 page for an overview of MariaDB 5.5.

The Release Notes page has some notes on the release. There is also a Changelog available for those who are interested.

Sources, binaries, and package downloads are available from our network of MariaDB mirrors. Debian and Ubuntu packages are available from our mirrored apt repositories. We have created a sources.list generator for creating sources.list entries.

The benchmark is DBT3, an implementation of the TPC-H specification. DBT3 is written in C and hosted at Sourceforge.

The DBT3 benchmark can run at different scale factors – defining the size of the database. I used a scale factor of 30 which yields ~30GB of raw data and ~48GB of disk footprint. The machine running the benchmark had 16G of memory.

InnoDB has the problem of fluctuating table statistics, leading to rather unpredictable query plans. For this reason the benchmark tables were created with the MyISAM engine. I will definitely run this benchmark vs. InnoDB in the future, but this requires some changes in our DBT3 automation scripts.

Both MySQL and MariaDB had to be tuned to use the new optimizer features. Specifically I turned on multi-range-read and batched-key-access. The MRR cost estimation was turned off because it’s not production ready in neither MySQL-5.6 nor MariaDB. For details see the tarball with the configuration files.

The following concentrates on the DBT3 Power Test which consists of 22 rather heavy JOIN queries. Each query was run 5 times on cold caches (server restart + file system cache cleared). Query execution time was limited by a 2 hour timeout. Execution time varies between 10 seconds and >2000 seconds, so for the following picture the execution time was normalized (MariaDB = 100%). The colored bar shows the median and the whiskers show min and max:

Here we can already see that MySQL-5.5 cannot cope well with this type of load. MySQL-5.6 has improved on many queries, but then again for query 3 or 8 it is even worse than 5.5. Rather a mystery is query 22 where MySQL 5.5 comes in first.

For more details, here is a table with the numbers. I have colored the rows to mark the winner (same colors as the diagram). If the difference is below 5% then it’s a draw. Those lines are not colored.

Query 11 is a draw because the difference is only 1 second (the granularity of time measurement). Query 11 showed a strange phenomenon for MariaDB: the first run took 43 seconds, subsequent runs only 13 seconds. This is probably a caching effect of the disk controller.

Neither MySQL version finishes query 18 within the time limit. None of the 3 candidates finishes query 20 within the limit.

Query execution plans differed between the candidates. Sometimes I could tweak the results by forcing the known good join order (using straight_join). I.e. on query 7 MariaDB used a different join order. When I forced the MySQL plan, then MariaDB needed only ~70% of the MySQL time. Or for query 12 MySQL 5.5 used a different plan as the others. After forcing the better join order, all 3 came it at the same time.

Finally I have another diagram, this time showing the details for the region around 100%.

If you want to run the DBT3 benchmark on your own, then you can use our DBT3 scripts. I have tarred up the configuration files for those scripts and the extracted raw data for download here.

(I recommend watching it in full screen 720p, so you can see the details.)

Some links:

• The MariaDB homepage
• The AskMonty Knowledgebase
• The MariaDB Downloads page
• Installing MariaDB on Windows documentation
• The HeidiSQL homepage

Acknowledgments:

A big thanks to Vladislav Vaintroub, MariaDB’s Windows guru, and to Rasmus Johansson for help with the screencast.

If you are not familiar with the term, please read the Knowledge Base article about it.

The main design goal of the thread pool is to increase the scalability of the MariaDB server with many concurrent connections. In order to test and demonstrate this, I have run the sysbench OLTP RO benchmark with up to 4096 threads to compare the new pool-of-threads and the traditional thread-per-connection scheduler:

Benchmark description:

• sysbench multi table OLTP, readonly
• 16 tables, totaling 40 mio rows (~10G of data)
• 16G buffer pool – result is independent of disk performance
• mysqld bound to 16 cpu cores, sysbench to the other 8

Read/write OLTP benchmark results will be published as soon as they are available.

Raw benchmark results and the scripts used can be downloaded here

PS:

Let me add few more words about binding cpu cores and thread pool configuration.

Sysbench-0.5 which was used for this benchmark, turned out to be quite a cpu hog; especially for high concurrency levels. If both mysqld and sysbench are allowed to run on all cpu cores, they will fight for resources – which will result in artificially bad results with many threads. With 4 cores for sysbench and 20 for mysqld, sysbench itself became the bottleneck. So I ended with 8 cores for sysbench (leaving some room here) and 16 for mysqld.

On UNIX, the MariaDB thread pool normally needs no configuration because it autoconfigures thread-pool-size to the number of cpu cores (this depends on sysconf(3) to implement _SC_NPROCESSORS_ONLN) which is in almost all cases the optimal size. If one binds mysqld to a subset of cpu cores, one should set thread-pool-size manually to the number of cpu cores given to mysqld.