From: | David Kerr <dmk(at)mr-paradox(dot)net> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgres Clustering Options |
Date: | 2009-11-11 18:13:05 |
Message-ID: | 20091111181305.GA24600@mr-paradox.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Nov 11, 2009 at 09:40:21AM -0800, John R Pierce wrote:
- David Kerr wrote:
- >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.
I'll look into Fencing this is the first i've heard of that. But everything
else you mentioned is exactly how I planned on doing it. so that's good
news =)
Thanks!
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | David Kerr | 2009-11-11 18:16:34 | Re: Postgres Clustering Options |
Previous Message | Greg Smith | 2009-11-11 18:11:52 | Re: Postgres Clustering Options |