Thread: High Avaliable in the PostgreSQL.

Hi,


    I need solution to PostgreSQL for High Available, originally
was 99,7% but considering the current necessities, change percentual
to 99,99%. I think in solution probability  pgpool-2 or Heartbeat +
GFS. The PostgreSQL servers will be in different physical places.

     Suggestions?



Kind Regards,
--
Fernando Ike
http://www.midstorm.org/~fike/weblog

Different physical places, I hope high bandwidth + low latency :)


On Wed, 30 May 2007, Fernando Ike de Oliveira wrote:

> Hi,
>
>
>     I need solution to PostgreSQL for High Available, originally
> was 99,7% but considering the current necessities, change percentual
> to 99,99%. I think in solution probability  pgpool-2 or Heartbeat +
> GFS. The PostgreSQL servers will be in different physical places.
>
>     Suggestions?
>
>
>
> Kind Regards,
>

--
Louis Gonzales
louis.gonzales@linuxlouis.net
http://www.linuxlouis.net

On Wed, May 30, 2007 at 04:42:08PM -0300, Fernando Ike de Oliveira wrote:
> was 99,7% but considering the current necessities, change percentual
> to 99,99%. I think in solution probability  pgpool-2 or Heartbeat +
> GFS. The PostgreSQL servers will be in different physical places.

I would be very interested to see a set-up that can actually
guarantee 99.99% uptime across a wide area link.  What write speeds
do you need in the database?  What is your tolerance for loss of
committed data?

A
--
Andrew Sullivan  | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
        --H.W. Fowler

On Wed, 2007-05-30 at 17:18 -0400, Andrew Sullivan wrote:
> On Wed, May 30, 2007 at 04:42:08PM -0300, Fernando Ike de Oliveira wrote:
> > was 99,7% but considering the current necessities, change percentual
> > to 99,99%. I think in solution probability  pgpool-2 or Heartbeat +
> > GFS. The PostgreSQL servers will be in different physical places.
> I would be very interested to see a set-up that can actually
> guarantee 99.99% uptime across a wide area link.

Sure it can be done.  Get two SANs that support replication, redundant
high-speed WAN links, high end servers, large UPSs, and generators.

It is just extremely expensive. :)
--
Adam Tauno Williams, Network & Systems Administrator
Consultant - http://www.whitemiceconsulting.com
Developer - http://www.opengroupware.org

On Wed, May 30, 2007 at 06:12:02PM -0400, Adam Tauno Williams wrote:
>
> Sure it can be done.  Get two SANs that support replication, redundant
> high-speed WAN links, high end servers, large UPSs, and generators.

Most SANs that I've seen aren't in "geographically separate"
locations in the way most think of this.  It's usually metronet --
it's not even a different city.  That's a poor disaster prevention
strategy, although it might be worth it as step one.  (If you can
take the latency, of course, you can make this go further, but true
both-coast solutions, for instance, will make the latency such that
users will certainly be able to see it.)

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
However important originality may be in some fields, restraint and
adherence to procedure emerge as the more significant virtues in a
great many others.   --Alain de Botton

HP was providing CA (Continuous Access) software that was claimed to provide WAN SAN replication by repeating IO in exactly the sequence it was generated on the master, to the slave. SO while there was a delay, updates on the slave would be sequentially intact, providing a good level of integrity for database rollback on the slave in the event of recovery on the slave / DR system. I'm not sure this would be sufficient for 99.9% uptime though, as there would be some startup requirements on the slave.

Hi!

We have a PostgreSQL cluster that is runnign on tens of server on
different colocations.
Failovers / switchovers between colocations can be done per server.
Uptime has been
 >99.9%. All the software is opensource and has gone through
intensive live testing.

Our cluster is running on:
skytools:
    * londiste (replica)
         * pgq        (generic queueing system)
         * walmgr  (wal replica manager)
http://pgfoundry.org/projects/skytools/

plproxy             (remote calls language)
http://pgfoundry.org/projects/plproxy/

pgbouncer
http://pgfoundry.org/projects/pgbouncer/

BR,
Kristo

On 30.05.2007, at 22:42, Fernando Ike de Oliveira wrote:

> Hi,
>
>
>     I need solution to PostgreSQL for High Available, originally
> was 99,7% but considering the current necessities, change percentual
> to 99,99%. I think in solution probability  pgpool-2 or Heartbeat +
> GFS. The PostgreSQL servers will be in different physical places.
>
>      Suggestions?
>
>
>
> Kind Regards,
> --
> Fernando Ike
> http://www.midstorm.org/~fike/weblog
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq

On Thu, May 31, 2007 at 05:30:20PM +1200, adey wrote:
> HP was providing CA (Continuous Access) software that was claimed to provide
> WAN SAN replication by repeating IO in exactly the sequence it was generated
> on the master, to the slave.

The CA stuff, or anything else built on FCIP, is pretty cool, but I'd
worry a little about latency.  Certainly your costs are going to be
high on transit, but if the data and uptime are worth it, you could
do it.  The big issue here is the same as in any other
failover-to-other-node case -- you have to be _super_ sure that the
failing master writer is dead and disconnected, and across a wide
area, this is going to be very tough to do.  I think you'd have to
spend a fair amount of time doing risk analysis of conflicting
commits happening in both sites (if the WAN link goes down because,
say, some genius decides to run a backhoe through the fiber going out
of your "primary" city, you could find your secondary site decides to
promote itself.  But the primary site might still have transactions
in flight.)

> system. I'm not sure this would be sufficient for 99.9% uptime though, as
> there would be some startup requirements on the slave.

Right, and the requirement was actually upped to 99.99%, which is
approximately 1 hour of allowable downtime a year.  That is a very
high bar.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
Users never remark, "Wow, this software may be buggy and hard
to use, but at least there is a lot of code underneath."
        --Damien Katz