From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Best replication solution? |
Date: | 2009-04-08 07:15:28 |
Message-ID: | 49DC4F10.6090302@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Andrew Sullivan wrote:
>
> 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.
>
>
>
Yes, and nicely explained!
> (on Londiste DDL + slave chaining)...
> 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.
>
>
>
>
Yeah, that's the challenge!
Personally I would like DDL to be possible without any special wrappers
or precautions, as the usual (accidental) breakage I end up looking at
in Slony is because someone (or an app's upgrade script) has performed
an ALTER TABLE directly on the master schema...
Cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Wakeling | 2009-04-08 10:35:51 | Re: plpgsql arrays |
Previous Message | Bruce Momjian | 2009-04-07 22:49:22 | Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 |