SUMMARY
-------
Have a replication slave that is always lagging 30 minutes behind
(configurable).

New syntax:

  CHANGE MASTER TO MASTER_DELAY=<TIME>;

  <TIME> is of datatype TIME.

(See also BUG#28760)


REQUIREMENT
-----------
The slave SQL thread will only execute binlog events if the (master)
timestamp in the binlog event plus delay time is less than slave system
time.

The slave should take the known time difference between master and slave into
account, so the delay time is independent of any unsynchronized clocks.


DECISIONS/OPINIONS
------------------
- 2006-03-15: Elliot says that we should do this for 5.2


LIMITATIONS
-----------
We will not implement any server options, since
1) options take time in test suite, and
2) the rpl options will disappear in the future when we push
   multi-source (WL#1697).


BACKGROUND
----------
This was a suggestion from Jeremy Zawodny at OSCON, July 2001, as a
discussion idea:

Add a feature to allow time-delayed replication.  Example cited by
Jeremy was need for delayed release of financial data which does not
propogate to slaves until after a set interval.

It could be implemented as an option 
--replication-delay=xxx seconds (xxx=0 means no delay)
and pseudocode like this in the slave :

if (replication-delay>0)
	{
	// beware of overflow/underflow below
	secs_to_wait = date_of_this_query_on_master + replication_delay - now ;
	if (secs_to_wait > 0)
		sleep secs_to_wait seconds ;
	}


Kristian Koehntopp writes:

TDS: Time delayed SQL_THREAD (Have a replication slave that is always
lagging 30 minutes behind).

Currently, replication is a rolling recovery: To set up replication you
restore from a full dump with a binlog position. You then continously
download binlog and roll forward. In case of a master crash a slave is a
readily recovered instance (as opposed to a backup, which still has to be
restored).

This protects against crashes, but not against oopses.

A time delayed slave (TDS) is a nice protection against oopses.


Sugar on top addendum: With the binlog being a table, any table type,
it will be very easy to delete an oopsing statement out of the
unapplied binlog queue. Currently, a simple time delayed slave will
protect you against oopses, but it will be very hard to extract the
relevant binlog portion out of the TDS replication log skipping the
oopsing statement.

With a MyISAM binlog table, it is just a matter of DELETE FROM
REPLICATION.BINLOG WHERE STATEMENT_ID = 1717;


WORK IN PROGRESS
----------------

2008-11-25 Sven uploaded file attachment containing a patch against a 6.0 tree
(the tree was from around May 2008)

Todo:
 - Check a new server can read old master.info / relay-log.info.
 - Check that we hold appropriate locks when accessing rli. Check that locking
order is consistent with other places where the locks are used.
 - Replace 'include/show_slave_status' by 'query_get_value(show slave status,
Column_name, 1)' in test case.
 - Mark test case as 'big'.
 - Update other tests where the result contains output from show slave status.
Note: please don't just update the result file. Update also the test file, and
replace all calls to show slave status (or include/show_slave_status) by
query_get_value(show slave status, Column_name, 1), so that only the relevant
column is printed to the include file. Get rid of include/show_slave_status.inc
if it is no longer used after this.

Included in HLD above.

Implementation

--------------

1. Add to rpl_rli.cc:

 

   time_t  delay; 



2. Add CHANGE MASTER syntax that sets delay.



3. Add to slave.cc:exec_relay_log_event

   (before exec_res = ev->exec_event):



   if (rpl->delay > 0)

   {

	if (event-timestamp + rpl->delay > now)

	      /* Clean up memory etc */

              /* exit function */

	}

   }

You must be logged in to tag this worklog