and seeing the following error,

2007-08-24T16:09:17 slave running 0 seconds behind
Use of uninitialized value in concatenation (.) or string at /usr/bin/mysql-slave-delay line 269.

Any ideas?

It could be that the .my.cnf didn’t work because the tool only reads the [mysql] section of the file, so if you have a [client] section it wouldn’t read that. Maybe that should be changed; I can’t decide.

In the scenario you describe, I think you’re talking about A->B->A replication. If you run the tool against B, it will only slow B getting the changes from A. This is because (I assume) you’ll have both servers configured with log_slave_updates. So an event on A will go to B’s relay log, sit for half an hour, execute, go into B’s binary log, go to A’s relay log — and be ignored, since it came from A to begin with. However, events on B will go into B’s binary log, A’s relay log, and get executed on A right away.

If you are talking about A->B->C replication, though, it’s different. A’s event will be delayed half an hour on B, then go into B’s binary log and then to C’s relay log, delayed half an hour. So in case you’re thinking about trying to delay B but not C, I don’t think you can do it.

This conversation brings up an interesting thought: the relay logs could be delayed too. I can’t think of why that would be useful right now, though.

Otherwise it does great for setting a 30m delay, and I see no problems (yet – still stress-testing it) with putting it into production. Any bugs will get sent up the chain, I promise :)

The error msgs I spoke are these (sanitized) – doesn’t seem to slow anything down at all, though, so I’m not particularly worried about seeing them. That, and it was mentioned in the docs anyway. For the rubberneckers, here’s what pops up (success, failure, success, failure, etc – all notes):
—
070808 8:15:36 [Note] Slave SQL thread initialized, starting replication in log ‘(binlog).000001′ at position 3437288, relay log ‘./(my)-relay-bin.000004′ position: 2650095
070808 8:15:51 [Note] Error reading relay log event: slave SQL thread was killed
070808 8:45:52 [Note] Slave SQL thread initialized, starting replication in log ‘(binlog).000001′ at position 3454088, relay log ‘./(my)-relay-bin.000004′ position: 2666895
070808 8:46:07 [Note] Error reading relay log event: slave SQL thread was killed
070808 9:16:07 [Note] Slave SQL thread initialized, starting replication in log ‘(binlog).000001′ at position 3471168, relay log ‘./(my)-relay-bin.000004′ position: 2683975
070808 9:16:22 [Note] Error reading relay log event: slave SQL thread was killed
—

Like I said, no worries, and everything works as advertised. Just figured you’d want to peek at ‘em.

I do have something to ponder, though; the slave server I implemented this on is about to be in the middle of a daisy-chain where two-way replication occurs. This is actually good in that changes I make to this DB propagate out immediately, while inbound changes are delayed. That said, I’m about to add another DB machine parallel to it (for a poor-man’s RAC rig w/ heartbeat/STONITH/scripting).

Is there a way to rig a delay for only one specific master, while letting the other roll its changes right in? I suspect that’s part of what the master binary DB check can be used for, but I’m not sure.

If not, no worries – I can just set the new DB to replicate off the same one that my first one does, set up the STONITH/heartbeat and scripting, and possibly create a replication loop of sorts as a ‘sanity check’ (I haven’t even checked to see if that’s possible w/o inducing problems yet). If that works I’ll document the whole thing (I have to document it anyway) and send it along w/ all the names/users/etc info sanitized out.

Besides, this is rather fun (and they pay me for it)… :)

Cheers!

/P