Me in front of the Sagrada Família in Barcelona.

Several MariaDB developers are attending SkySQL’s annual engineering meeting being held this week in Barcelona. While some of the discussions are SkySQL-specific (customers, internal projects, and so on), there are, naturally, lots of MariaDB discussions happening.

Patrik Sallner, CEO of SkySQL, opened the meeting this morning with a short presentation about SkySQL’s goals for 2014. While the plan includes standard business-like things that include growing the company and sales goals, the top two goals for 2014 are:

  1. Help make MariaDB into the leading open source database

  2. Help increase awareness and adoption of MariaDB

Looking back at 2013, it was an excellent year for MariaDB. It is now the default database in Fedora, OpenSUSE, Mageia, and others and it is included in the recently released Red Hat Enterprise Linux 7  preview. During the last days of 2013 MariaDB was also made part of Debian.

During the daily summary, we talked about the 10.0 release plan, focusing on 10.0.8, planning the Release Candidates (RCs) and we now even have a pretty good idea when 10.0 will go GA (you can see this in JIRA).

For the upcoming 10.0.8 release there are 40 bugs being worked on. The planned release date is 31 January 2014, and this will be the first RC. The 10.0.9 release, planned for the end of February, would also be another RC release. The MariaDB 10.0.10 release (planned release date: end of March) is planned to be the first 10.0 GA release.

Lastly, a widely discussed topic among the MariaDB developers today was the performance of MariaDB 10.0, where there already exist a few new patches and quite a few further ideas for improvments. More about this in a separate blog post later.

For now, a big hello from Barcelona!

The MariaDB project is pleased to announce the immediate availability of MariaDB 10.0.7. This is a Beta release. See the Release Notes and Changelog for detailed information on this release and the What is MariaDB 10.0? page in the MariaDB Knowledge Base for general information about the MariaDB 10.0 series.

Download MariaDB 10.0.7

Release Notes Changelog What is MariaDB 10.0?

Also see MariaDB 10.0 Beta launched – an important milestone.

Thanks, and enjoy MariaDB!

This is both hilarious and sad. The new MySQL 5.7 milestone release presents a new feature — replication filters are now dynamic. This is a great and long awaited feature, no doubt about it.

In short, for years MySQL slaves could filter the incoming stream of replication events based on the database or table name these events were applicable to. These filters were configured using the my.cnf file (or command-line), in particular with the following variables:

Naturally, users wanted to be able to change the values of these options without having to restart the server. And eventually Davi Arnaut implemented it. MariaDB got it as a contribution back in version 5.5.22. Since that release these options in MariaDB have been dynamic system variables and one could change them at will. For example,

Now, I understand that sometimes we might implement a certain useful feature first. And I understand that in that case Oracle might want to have it, while not looking like they’re following MariaDB. Of course not! The feature must be totally original. With completely incompatible syntax. Most recent examples would be EXPLAIN FOR CONNECTION in MySQL 5.7.2 about a year after SHOW EXPLAIN was introduced in MariaDB, and multi-source replication using “channels”, while MariaDB has already been using named slaves for quite a while.

But really, there should be some logic in it. Admittedly, EXPLAIN FOR CONNECTION isn’t worse than SHOW EXPLAIN. And multi-source “channels” look just fine, syntax-wise. Still, if there is a command-line option, there (almost always) is a corresponding system variable, visible in SHOW VARIABLES. One (almost always) changes the value of the option by assigning a new value to the corresponding variable. There is only one way of doing it.

Alas, we have taken this way in MariaDB. So, by strictly adhering to the NIH principle (and, I suspect, internal Oracle policies), MySQL developers simply had to invent a different way of changing server options. Lo and behold, CHANGE REPLICATION FILTER statement. Examples are:

Well done. Common sense? Nope, not in this case.