Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 4DEA8650004 for ; Thu, 21 Aug 2008 15:26:06 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 63450-03 for ; Thu, 21 Aug 2008 15:25:55 -0300 (ADT) X-Greylist: delayed 00:32:00.502652 by SQLgrey-1.7.6 Received: from crestone.coronasolutions.com (crestone.coronasolutions.com [66.45.104.24]) by postgresql.org (Postfix) with ESMTP id 88341650098 for ; Thu, 21 Aug 2008 15:25:56 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by crestone.coronasolutions.com (Postfix) with ESMTP id F1F0EACC0E3; Thu, 21 Aug 2008 11:53:52 -0600 (MDT) Received: from crestone.coronasolutions.com ([127.0.0.1]) by localhost (crestone.coronasolutions.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29547-07; Thu, 21 Aug 2008 11:53:52 -0600 (MDT) Received: from mac.local (dan-mac [10.1.250.4]) by crestone.coronasolutions.com (Postfix) with ESMTP id DDBBBACC08D for ; Thu, 21 Aug 2008 11:53:51 -0600 (MDT) Message-ID: <48ADABAF.8030602@drivefaster.net> Date: Thu, 21 Aug 2008 11:53:51 -0600 From: Dan Harris User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: The state of PG replication in 2008/Q2? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at coronasolutions.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.899 tagged_above=0 required=5 tests=FS_REPLICA=1.179, SARE_SPEC_REPLICA=0.72 X-Spam-Level: * X-Archive-Number: 200808/256 X-Sequence-Number: 31137 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