Andrew Sullivan <ajs at crankycanuck.ca> wrote:

> On Sun, Oct 15, 2006 at 10:15:32AM -0400, Bill Moran wrote:
> > "Andrew And" <andcop2006 at gmail.com> wrote:
> > In my tests, I've been able to push the database hard enough that the
> > slave gets several 1000 records out of sync with the master.  When I
> > stop the traffic generator, though, Slony is able to catch everything
> > back up in less than 5 seconds.
> 
> Yes, but there is not, in general, a way to guarantee that the
> replica will never be more than n seconds behind transactions
> committed on the origin, which is what I think the OP wanted.  This
> is effectively impossible, because we don't control the OS or the
> network.  If you could guarantee certain levels of network flow, and
> guarantee some maximum load on your origin, you should be able to be
> pretty certain of throughput.  But I still wouldn't commit to a hard
> number that was not somewhere in the 60 second range.

Actually, a better way would be to control PostgreSQL.  If Slony could
tell PostgreSQL to stop committing transactions, then it could monitor
its own progress and this would allow an administrator to define a
setting that said, for example, never let the slaves get more than 50
transactions behind.  When the backlog got to 50, the master would block
on new transactions until the slaves caught up.

Such a system would allow admins to determine how much out of sync they
are willing to accept, and it would still allow the master to handle
spikes and recover.

I don't know how difficult this would be to implement, it's just a
thought.

-- 
Bill Moran

If you take sexual advantage of her, you're going to burn in a very special
level of hell. A level they reserve for child molesters and people who talk
at the theater.

	Shepherd Book