On Wed, Apr 20, 2011 at 12:24 PM, Greg Stark <gsstark@mit.edu> wrote:
> I haven't read the patch but are you delaying delivering the log or
> delaying replaying it? I think you actually want the latter so in case
> of a real failure you can choose between replaying the last 5 minutes
> and recovering everything or intentionally dropping that history if
> the failure was caused by an application problem.
>
Ok, so I read the patch. That wasn't so hard.
You did implement it the way I described so great.
However you did it by comparing the server timestamp and the slave
timestamp. I think we should avoid that. Synchronizing clocks is a
surprisingly hard problem and it would really be great if the whole
system kept working if the clocks were out of sync.
I don't think that's impossible, though it's a bit inconvenient. We
would need to keep track of the most recent timestamp received from
the master and pause recovery if we reach recovery on a record that's
less than five minutes older than that record. This means we're
comparing only master timestamps to each other. It does mean if the
log transfer lags then recovery will lag unnecessarily. And it means
the process of receiving logs is complicated by having to keep track
of this timestamp.
--
greg