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@xxxxxxxxxxxxxxx -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
