pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Mark Kirkwood <markir@paradise.net.nz>
To: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-performance@postgresql.org
Subject: Re: Best replication solution?
Date: Wed, 08 Apr 2009 19:15:28 +1200
Message-ID: <49DC4F10.6090302@paradise.net.nz> (raw)
In-Reply-To: <20090407171803.GQ14950@shinkuro.com>
References: <49D8FA31.8010407@on-track.ca>
	<20090406123529.GA14675@shinkuro.com>
	<49DB2B66.1080801@paradise.net.nz>
	<20090407171803.GQ14950@shinkuro.com>

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




view thread (17+ messages)  latest in thread

Message-ID: <49DC4F10.6090302@paradise.net.nz>
Permalink:  ../49DC4F10.6090302@paradise.net.nz/
Also on:    postgresql.org/message-id/49DC4F10.6090302@paradise.net.nz

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: markir@paradise.net.nz, ajs@crankycanuck.ca
  Subject: Re: Best replication solution?
  In-Reply-To: <49DC4F10.6090302@paradise.net.nz>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox