Re: HA options - Mailing list pgsql-general

From Tim Uckun
Subject Re: HA options
Date
Msg-id CAGuHJrNoaC1OUOjcbfekZxULaORgA42GgbZZNQhDMWyCzjs8ng@mail.gmail.com
Whole thread Raw
In response to Re: HA options  (Andy Colson <andy@squeakycode.net>)
Responses Re: HA options  (David Morton <davidmorton@xtra.co.nz>)
List pgsql-general
>
> I wonder.  If its a write heavy database, I totally agree with you.  But if
> its mostly read-only, and mostly fits in ram, then a pgpool of servers
> should be faster.
>
> Be nice to know the usage patterns of this database. (and size).
>

In this case the databases are small to medium and the usage is
relatively light.  The main concern is availability and not
scalability although that will probably come into play later on. For
our performance profile we are OK with using virtual servers *at this
time*.

I will need HA no matter what underlying hardware I use but as you
guys have pointed out using virtual servers means a shared nothing
approach for now so I was asking about the pros and cons of the
various projects I listed and people's experiences of them.

I have read the basic introductions to the various projects and have a
rough idea of what they are trying to do but when it comes to
implement something like this the devil is in the details. I am
curious if anybody has used them in production environments and if
given a chance they would go the same route or try something
different.

My use case is pretty simple and I would think extremely common which
is that "the database must be up no matter what".  In addition to
having some sort of a failover I want to implement log shipping to a
remote location and keeping a hot/warm standby there.  Anything over
and above that would be icing on the cake. Things like adding nodes on
the fly, being able to upgrade without downtime, failing back without
having to do a full backup, multi master, etc are very desirable
things to have but *at this time* I can do without them.

Cheers.

pgsql-general by date:

Previous
From: Andy Colson
Date:
Subject: Re: HA options
Next
From: David Morton
Date:
Subject: Re: HA options