On Mon, February 18, 2008 9:39 pm, Christopher Browne wrote:
> ...

Thanks for the comments, Christopher.  I accidentally posted to Andrew
only, so here's my response to the list:

I've tackled the lag problem from another angle:  refactored my cluster
systems to sleep whenever the lag status on master exceeds a threshold
(and keep sleeping until things are back under control).

When things go quiet (system activity-wise) to allow replication catch-up,
it *is* a waste of resources, but this is the lesser of two evils.

btw, I've occasionally noticed the following slony activity on the slaves:

"update table set id=100 where id=100"

(where id is the primary key)

wtf?  Presumably this is some kind of replication artifact or -something-.
Problem is, this kind of weird update on *HUGE* tables on the slaves could
be what sometimes contributes to lag...

Any idea what this is about?

Regards
Henry