Hi
On 22 January 2013 15:22, Keith Ouellette <Keith.Ouellette@airgas.com> wrote:
> Kevin,
>
> I understand the confusion. What I am being asked to do is the following:
>
> 1. Use pacemaker to determine who should be the Master node so it can assign a virtual IP to it.
>
> 2. Use the lsb:postgresql RA as a master resource to monitor the postgresql process on each node
>
> 3. Failover to the slave node when the master fails. Pacemaker moves over the virtual IP. I detect that in a process
Irun (script that checks the location of the virtual IP) and promote the slave to master using the trigger file.
>
> 4. When the failed server comes back up, I detect that it should no longer be master using the process and sync it to
thenew master, create the recovery.conf file and restart the postgres process.
How about at step 4:
When the failed server comes back up, do not automatically start
postgres, or in some other way prevent Pacemaker from thinking the
node is ready. Then, when you've done whatever you need to to get it
ready as a slave, start it up and Pacemaker can see that it is now
ready.
> The issue is when we restart the postgresql, Pacemaker takes that node "down" in alarm. The team lead does not want
that.I am just wondering if it was possible to bring up the recovered server without restarting the postgresql process?
I think the main thing is that until you've finished reconfiguring
postgres it is not "recovered", so you need to make sure Pacemaker
doesn't think it is recovered before it's actually ready.
Unless I've missed something :) (I have no experience with Pacemaker
or postgres replication.)
--
Michael Wood <esiotrot@gmail.com>
