Re: The state of PG replication in 2008/Q2? - Mailing list 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@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance