Evil replication management

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.

About these ads
This entry was posted in mysql and tagged , , . Bookmark the permalink.

5 Responses to Evil replication management

  1. Arjen Lentz says:

    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.

  2. Toby says:

    “Having it in server would be best?” — I disagree entierly! training in gdb should be an important part of being a MySQL DBA.

  3. Platonides says:

    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…

  4. erkules says:

    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)

  5. Pingback: Log Buffer #157: a Carnival of the Vanities for DBAs | Pythian Group Blog

Comments are closed.