From: | Toby Corkindale <toby(dot)corkindale(at)strategicdata(dot)com(dot)au> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | practical Fail-over methods (was: streaming replication trigger file) |
Date: | 2011-07-26 05:29:13 |
Message-ID: | 4E2E50A9.5050305@strategicdata.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 16/06/11 18:44, John R Pierce wrote:
> On 06/16/11 1:31 AM, AI Rumman wrote:
>> When I manually create the C:\\pg\\stopreplication\\standby.txt' file,
>> then it is working. That is, B is becoming the master.
>> So, my question is, how this trigger file should be created so that B
>> will become master automatically as soon as A goes down?
>
> you need cluster management software, such as Heartbeat (on linux) or
> Veritas Cluster Service (on various operating systems) configured to
> detect system failure, and reconfigure the slave to be the master. This
> software also generally is used to manage things like the shared IP
>
> really really REALLY important is what to do when the failed original
> master is brought back up. it can NOT be allowed to wake up thinking its
> still a master since its lacking any updates since it went down, instead
> it has to be reconfigured to be a new slave.
Just following on a bit from this..
It seems fairly hard to get that part right - ensuring that the
former-master stays down, and also that automatic scripts don't run off
and convert the wrong one into a new standby either.
Do you mind if I ask how other people are doing this? Are you finding
heartbeat, keepalived or pacemaker better? What sort of ways are you
triggering the fail-over by?
And, how are you avoiding having a former-master come back up thinking
it's still the master.. yet still coping with a situation where, say,
first one machine, then the other, reboot. (thus easily triggering a
failover to one, then it going down and the other coming up and looking
like it's alone in the world)
Thanks!
Toby
From | Date | Subject | |
---|---|---|---|
Next Message | Sim Zacks | 2011-07-26 08:04:02 | Re: Implementing "thick"/"fat" databases |
Previous Message | Tom Lane | 2011-07-26 03:25:18 | Re: Error calling PG_RETURN_NULL() |