Re: Postgres Clustering Options - Mailing list pgsql-general

From John R Pierce
Subject Re: Postgres Clustering Options
Date
Msg-id 4AFAF705.1070703@hogranch.com
Whole thread Raw
In response to Postgres Clustering Options  (David Kerr <dmk@mr-paradox.net>)
Responses Re: Postgres Clustering Options  (Greg Smith <greg@2ndquadrant.com>)
Re: Postgres Clustering Options  (David Kerr <dmk@mr-paradox.net>)
List pgsql-general
David Kerr wrote:
> I'm trying to meet a very high uptime requirement in a high performance environment.
>
> to do this we will need to have some form of cluster for our databases
>
> What I plan on doing is:
>
> Postgres installed on a Cluster configured in active/passive (both pointing to the same SAN
> (If PG or the OS fails we trigger a failover to the passive node)
>
> Log shipping between that cluster and a single PG Instance off site.
>
>
> Is this a common/reccomended method of handling clusterin with Postgres? google searches
> basically point to using a replication based solution, which i don't think would meet my
> performance demands.
>
> Does anyone have expereince with this or a similar setup that they could share with me?
>

thats your classic database cluster.        the reason you don't see
much of that in online writeups is that the high availability SAN
hardware is expensive

presumably you'd manage this with classic cluster managemetn software
(veritas cluster, sun cluster, redhat cluster, heartbeat, or whatever is
appropriate to your environment.     commercial cluster vendors
generally recommend doing the cluster 'heartbeat' over at least two
seperate network links so that a network failure doesn't trigger a false
failover.     implementing 'fencing' in your storage switch is also a
very good idea, most fencing systems can send commands to common
fiberchannel switches to disable the access port or soft zone of the
current standby server so ti can't accidentally mount the storage.

your applications should be tolerant of database server disconnects, and
know how to reconnect and restart the transaction that was in progress.

pgsql-general by date:

Previous
From: Ben Chobot
Date:
Subject: Re: Postgres Clustering Options
Next
From: akp geek
Date:
Subject: Re: Incremental Backups in postgres