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.