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: F58B66EE-6F38-4876-B0EF-C8C46740FF7D@globalinn.com (view raw or flat)
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 (http://www.postgresql.org/docs/8.1/static/backup-online.html 
)

For Master-Slave replication i think that Slony http://www.slony.info/  
is most up to date. But it does not support DDL changes.

You may wich to look at pgpool http://pgpool.projects.postgresql.org/  
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,
Mathias

http://www.pastbedti.me/


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:
> http://www.postgresql.org/mailpref/pgsql-performance

In response to

Responses

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-2014 The PostgreSQL Global Development Group