Skip site navigation (1) Skip section navigation (2)

Re: Core team statement on replication in PostgreSQL

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Robert Hodges <robert(dot)hodges(at)continuent(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>,"Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-06-01 21:14:39
Message-ID: 1212354879.18365.30.camel@huvostro (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacypgsql-hackers
On Thu, 2008-05-29 at 12:05 -0700, Robert Hodges wrote:
> Hi everyone, 
> First of all, I’m absolutely delighted that the PG community is
> thinking seriously about replication.  
> Second, having a solid, easy-to-use database availability solution
> that works more or less out of the box would be an enormous benefit to
> customers.  Availability is the single biggest problem for customers
> in my experience and as other people have commented the alternatives
> are not nice.  It’s an excellent idea to build off an existing feature
> —PITR is already pretty useful and the proposed features are solid
> next steps.  The fact that it does not solve all problems is not a
> drawback but means it’s likely to get done in a reasonable timeframe. 
> Third, you can’t stop with just this feature.  (This is the BUT part
> of the post.)  The use cases not covered by this feature area actually
> pretty large.  Here are a few that concern me: 
> 1.) Partial replication. 
> 2.) WAN replication. 

1.) & 2.) are better done asunc, the domain of Slony-I/Londiste

> 3.) Bi-directional replication.  (Yes, this is evil but there are
> problems where it is indispensable.) 

Sure, it is also a lot harder and always has several dimensions
(performanse/availability7locking) which play against each other

> 4.) Upgrade support.  Aside from database upgrade (how would this ever
> really work between versions?), it would not support zero-downtime app
> upgrades, which depend on bi-directional replication tricks. 

Or you could use zero-downtime  app upgrades, which don't depend on
this :P

> 5.) Heterogeneous replication. 
> 6.) Finally, performance scaling using scale-out over large numbers of
> replicas.  I think it’s possible to get tunnel vision on this—it’s not
> a big requirement in the PG community because people don’t use PG in
> the first place when they want to do this.  They use MySQL, which has
> very good replication for performance scaling, though it’s rather weak
> for availability.  

Again, doing scale-out over large number of replicas should either be
async or for sync use some broadcast channel to all slaves (and still be
a performance problem on master, as it has to wait for slowest slave).

> As a consequence, I don’t see how you can get around doing some sort
> of row-based replication like all the other databases. 

Is'nt WAL-base replication "some sort of row-based replication" ?

>  Now that people are starting to get religion on this issue I would
> strongly advocate a parallel effort to put in a change-set extraction
> API that would allow construction of comprehensive master/slave
> replication. 

Triggers. see pgQ's logtrigga()/logutrigga(). See slides for Marko
Kreen's presentation at pgCon08.

>  (Another approach would be to make it possible for third party apps
> to read the logs and regenerate SQL.) 

which logs ? WAL or SQL command logs ?

> There are existing models for how to do change set extraction; we have
> done it several times at my company already.  There are also research
> projects like GORDA that have looked fairly comprehensively at this
> problem.

pgQ with its triggers does a pretty good job of change-set extraction.


In response to


pgsql-hackers by date

Next:From: David FetterDate: 2008-06-01 23:33:55
Subject: == PostgreSQL Weekly News - June 01 2008 ==
Previous:From: Greg Sabino MullaneDate: 2008-06-01 21:13:05
Subject: Re: Overhauling GUCS

pgsql-advocacy by date

Next:From: Selena DeckelmannDate: 2008-06-02 02:37:57
Subject: Call for proposals for PDXPUG PgDay - due by June 20, 2008
Previous:From: Hannu KrosingDate: 2008-06-01 20:42:29
Subject: Re: Core team statement on replication in PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group