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

Re: The state of PG replication in 2008/Q2?

From: Mathias Stjernström <mathias(at)globalinn(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: The state of PG replication in 2008/Q2?
Date: 2008-08-21 20:53:05
Message-ID: (view raw or whole thread)
Lists: pgsql-performance
Hi Dan!

Its true, many of the replication options that exists for PostgreSQL  
have not seen any updates in a while.

If you only looking for redundancy and not a performance gain you  
should look at PostgreSQL PITR ( 

For Master-Slave replication i think that Slony  
is most up to date. But it does not support DDL changes.

You may wich to look at pgpool  
it supports Synchronous replication (wich is good for data integrity,  
but can be bad for performance).

These are some of the open source options. I do not have any  
experience with the commercial onces.

Best regards,

On 21 aug 2008, at 19.53, Dan Harris wrote:

> My company finally has the means to install a new database server  
> for replication.  I have Googled and found a lot of sparse  
> information out there regarding replication systems for PostgreSQL  
> and a lot of it looks very out-of-date.  Can I please get some ideas  
> from those of you that are currently using fail-over replication  
> systems?  What advantage does your solution have?  What are the  
> "gotchas" I need to worry about?
> My desire would be to have a parallel server that could act as a hot  
> standby system with automatic fail over in a multi-master role.  If  
> our primary server goes down for whatever reason, the secondary  
> would take over and handle the load seamlessly.  I think this is  
> really the "holy grail" scenario and I understand how difficult it  
> is to achieve.  Especially since we make frequent use of sequences  
> in our databases.  If MM is too difficult, I'm willing to accept a  
> hot-standby read-only system that will handle queries until we can  
> fix whatever ails the master.
> We are primary an OLAP environment but there is a constant stream of  
> inserts into the databases.  There are 47 different databases hosted  
> on the primary server and this number will continue to scale up to  
> whatever the server seems to support.  The reason I mention this  
> number is that it seems that those systems that make heavy use of  
> schema changes require a lot of "fiddling".  For a single database,  
> this doesn't seem too problematic, but any manual work involved and  
> administrative overhead will scale at the same rate as the database  
> count grows and I certainly want to minimize as much fiddling as  
> possible.
> We are using 8.3 and the total combined size for the PG data  
> directory is 226G.  Hopefully I didn't neglect to include more  
> relevant information.
> As always, thank you for your insight.
> -Dan
> -- 
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org 
> )
> To make changes to your subscription:

In response to


pgsql-performance by date

Next:From: Andrew SullivanDate: 2008-08-21 21:04:36
Subject: Re: The state of PG replication in 2008/Q2?
Previous:From: André VolpatoDate: 2008-08-21 20:05:12
Subject: Re: Postgres not using array

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