When one wants to script automated replication chain building, certain things are quite annoying, like immutable replication configuration variables. For example, at certain moments log_slave_updates is more than needed, and thats what the server says:
mysql> show variables like 'log_slave_updates'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | log_slave_updates | OFF | +-------------------+-------+ 1 row in set (0.00 sec) mysql> set global log_slave_updates=1; ERROR 1238 (HY000): Variable 'log_slave_updates' is a read only variable
Of course, there are few options, roll in-house fork (heheeeee!), restart your server, and keep warming up your tens of gigabytes of cache arenas, or wait for MySQL to ship a feature change in next major release. Then there are evil tactics:
mysql> system gdb -p $(pidof mysqld) -ex "set opt_log_slave_updates=1" -batch mysql> show variables like 'log_slave_updates'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | log_slave_updates | ON | +-------------------+-------+ 1 row in set (0.00 sec)
I don’t guarantee safety of this when slave is running, but… stopping and starting slave threads is somewhat cheaper, than stopping and starting big database instance, right?
What else can we do?
mysql> show slave status \G ... Replicate_Do_DB: test ... mysql> system gdb -p $(pidof mysqld) -ex 'call rpl_filter->add_do_db(strdup("hehehe"))' -batch mysql> show slave status \G ... Replicate_Do_DB: test,hehehe ...
It is actually possible to add all sorts of filters this way, rpl_filter.h can be good reference :) So now that you want to throw out some data from your slaves, restart isn’t needed. Unfortunately, deleting entries isn’t possible via rpl_filter methods, but you can always edit base_ilists, can’t you?
P.S. having this functionality inside server would definitely be best.
Purest Domas-evil, I love it ;-)
How about a commandline-interface for this that knows about all the relevant tweakable settings? This can also serve as a good TODO for those coding the server.
“Having it in server would be best?” — I disagree entierly! training in gdb should be an important part of being a MySQL DBA.
I’m afraid, you hot-patch the servers so much they won’t work when you need to restart them. :-)
You should consider changing to Microsoft based servers, I hear they don’t allow this flaws…
mysql> show variables like ‘log_slave_updates’;
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| log_slave_updates | OFF |
+——————-+——-+
1 row in set (0,00 sec)
mysql> system gdb -p $(pidof mysqld) -ex “set opt_log_slave_updates=1” -batch
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0x7fcef3768700 (LWP 4825)]
….
mysql> show variables like ‘log_slave_updates’;
ERROR 13 (HY000): Can’t get stat of ‘/tmp/#sql_12d9_0.CSV’ (Errcode: 2)