Re: Best replication solution?

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

In response to

Browse pgsql-performance by date

  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