On Tue, Apr 07, 2009 at 10:31:02PM +1200, Mark Kirkwood wrote:
>
> From my experience - gained from unwittingly being in the wrong place at
> the wrong time and so being volunteered into helping people with Slony
> failures - it seems to be quite possible to have nodes out of sync and
> not be entirely aware of it
I should have stated that differently. First, you're right that if
you don't know where to look or what to look for, you can easily be
unaware of nodes being out of sync. What's not a problem with Slony
is that the nodes can get out of internally consistent sync state: if
you have a node that is badly lagged, at least it represents, for
sure, an actual point in time of the origin set's history. Some of
the replication systems aren't as careful about this, and it's
possible to get the replica into a state that never happened on the
origin. That's much worse, in my view.
In addition, it is not possible that Slony's system tables report the
replica as being up to date without them actually being so, because
the system tables are updated in the same transaction as the data is
sent. It's hard to read those tables, however, because you have to
check every node and understand all the states.
> Complexity seems to be the major evil here.
Yes. Slony is massively complex.
> simpler to administer. Currently it lacks a couple of features Slony has
> (chained slaves and partial DDL support), but I'll be following its
> development closely - because if these can be added - whilst keeping the
> operator overhead (and the foot-gun) small, then this looks like a
> winner.
Well, those particular features -- which are indeed the source of much
of the complexity in Slony -- were planned in from the beginning.
Londiste aimed to be simpler, so it would be interesting to see
whether those features could be incorporated without the same
complication.
A
--
Andrew Sullivan
ajs@crankycanuck.ca