pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: RW <postgres@tauceti.net>
To: pgsql-performance@postgresql.org
Subject: Re: The state of PG replication in 2008/Q2?
Date: Fri, 22 Aug 2008 08:18:25 +0200
Message-ID: <48AE5A31.8090003@tauceti.net> (raw)
In-Reply-To: <48ADABAF.8030602@drivefaster.net>
References: <48ADABAF.8030602@drivefaster.net>


> 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.
>
>
If you really need "only" need automatic failover than use DRBD + Heartbeat
somebody already mentioned. We are using this solution since 3 years now.
With DRBD replication is done at filesystem block level. So you don't 
have to
bother about changes done with a DDL statement and Heartbeat will
automatically failover if one server goes down. It's really stable.

If you want MM you should give Cybercluster a try. 
(http://www.postgresql.at/english/pr_cybercluster_e.html)
They offer good support and is Open Source since a few month now.

Robert




view thread (17+ messages)  latest in thread

Message-ID: <48AE5A31.8090003@tauceti.net>
Permalink:  ../48AE5A31.8090003@tauceti.net/
Also on:    postgresql.org/message-id/48AE5A31.8090003@tauceti.net

 · 

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: postgres@tauceti.net
  Subject: Re: The state of PG replication in 2008/Q2?
  In-Reply-To: <48AE5A31.8090003@tauceti.net>

* 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