Re: 9.0 replication -- multiple hot_standby servers - Mailing list pgsql-general

From John R Pierce
Subject Re: 9.0 replication -- multiple hot_standby servers
Date
Msg-id 4CCB08A0.5060809@hogranch.com
Whole thread Raw
In response to 9.0 replication -- multiple hot_standby servers  (Dean Gibson AE7Q <yahoo@ae7q.net>)
List pgsql-general
On 10/28/10 11:25 PM, Dean Gibson AE7Q wrote:
> Two days ago I upgraded five DB boxes (for load balancing) from 8.3.0
> to 9.0.1 in order to use replication. The replication configuration
> went reasonably well, and now all the four "hot_standby" servers are
> (streaming) replicating just fine from the primary DB server.  If the
> primary fails and I "touch" the trigger file on one of the standby
> boxes, that goes into primary mode just as it should.  Of course, I
> have to externally redirect updates to the new server.
>
> My question is, how do I configure the other three (still) hot_standby
> boxes to now use the new primary?  Clearly I can change the
> "recovery.conf" file on each standby box, but that seems like an
> unnecessary nuisance.
>

I've not worked with the 9.0.x replication yet, so my comments are of a
more general nature...

A) keep it super simple.   complex schemes have a marvelous way of
finding corner cases and biting you in the @%%.

B) don't forget corner cases like a 'stoned' server that somehow isn't
communicating with the others and decides ITS the master when in fact
another node is running just fine.

robust cluster management systems like Veritas Cluster insist on
redundant inter-node heartbeat communications paths, and hardware
fencing support so only one node can possibly be 'master' at any given time.

pgsql-general by date:

Previous
From: "Cole, Tavin"
Date:
Subject: xor(bytea,bytea)
Next
From: "Dean Gibson (DB Administrator)"
Date:
Subject: 9.0 replication -- multiple hot_standby servers