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,
set global replicate_do_db = "mydb1,mydb2";
set global replicate_wild_ignore_table = "mydb1.local%";
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:
change replication filter replicate_do_db=(mydb1,mydb2);
change replication filter replicate_wild_ignore_table=('mydb1.local%');
Well done. Common sense? Nope, not in this case.