Comments on: MySQL: Time Delayed Replication

By: Frarseclata

Frarseclata — Mon, 13 Jun 2011 02:20:37 +0000

Just now examined the thread! great work.

By: jon

jon — Sat, 14 Jun 2008 16:23:03 +0000

Benpi –
I haven’t looked at the MySQL source, but I can’t imagine why it *wouldn’t* be possible. I just don’t think it’s a very high priority.

Obviously I like the idea, I said so in the above post

By: benpi

benpi — Fri, 13 Jun 2008 11:08:59 +0000

We can see a few tools floating around that implements delayed transaction by starting/stopping the replication thread on the slave. This method basically do the trick, but is indeed less than optimal. Not only because it’s a hack, and lacks fine grained control, and impose episodic burst loads on the network and master rep thread.

It would be in fact _way_ more useful if the slaves could still receive the replication logs in real time, as with standard replication, but they could only delay the effective execution of those logs on their database replicas. So that we could have a very efficient way to recover up to the last working point on a slave (ie. to tell a slave : “then now, dear slave, please apply every pending replog up to the transaction $nb, the one where the sysadmin borked the database / where some corruption happened”), then promote the slave as the new main database server, and get back to normal operations.

One could imagine a pool of daisy chained slaves running each with an increased delay (ie. slave1 lagging 1/2 h, slave2 lagging 1 h, slave3 1.5 h etc) : that way, we could choose to recover from the nearest (lesser lagging) slave that still have clean data, even if we discover the corruption a bit late, and we would have a very fast and flexible recovery-from-human-error mechanism. That would be, practically, a kind of real-time incremental hot standby backups (with almost-no-time recover from disaster)

What do you think about such a delayed replication flow ? is this possible/implementable in MySQL ?

By: jon

jon — Thu, 08 May 2008 20:33:17 +0000

I didn’t even realize this went back 7 years. Wow…

By: Jeremy Zawodny

Jeremy Zawodny — Thu, 08 May 2008 14:22:36 +0000

I had completely forgot that I suggested that back in 2001. Heh.

By: Xaprb

Xaprb — Thu, 08 May 2008 01:10:19 +0000

It’s useful enough, and enough people requested it, that Maatkit has a very elegant implementation of time-delayed replication. It does NOT rely on Seconds_behind_master, which is buggy and unreliable; neither does it read binary logs, which is unacceptably expensive.

By: bighard

bighard — Wed, 07 May 2008 20:38:58 +0000

been there, done that

we had a slave, lagging between 1-2hrs – not only for admin oopses, but also to recover from malicious user attacks.

since our traffic was hudge – during the day, the slave needed about the sime time to recover, as the lag was – eg, a 1h lag took 1h to catch up…

so every 15 minutes a perl script did start slave, checked if the lag is less than 2hrs – if it was, it did stop the slave, if it was larger, it left the slave running, and checked again in the next 15 minutes.