[Linux-ha-dev] Ordering of OCF Start, Stop and Monitor actions

Doug Knight dknight at wsi.com
Wed Mar 28 11:11:28 MDT 2007


One additional question that has come up as I've developed my notify
function: When the promote of the slave completes, and the post-promote
notify is sent out, is this post-promote notify sent to both the master
and slave nodes, or just to the slave?

Doug

On Wed, 2007-03-28 at 12:34 -0400, Doug Knight wrote:

> Hi Lars,
> I've gone through your comments below, and I think I understand this a
> bit better. Let me state what I think I need to do, and see if I've
> got it now (starting with Node A master and Node B slave):
> 
> Node A: PostgreSQL master gets demoted - completes (basically just
> stops PostgreSQL)
> Node B: PostgreSQL slave gets promoted - starts it up as new master
> server
> Node A: PostgreSQL demoted master gets a post notify call with promote
> notify operation
> 
> At this point I know heartbeat has brought the new master server up
> (node B), and I can safely rsync and restart the new slave server
> (node A). Nice and clean... Also, I need to remember that notify will
> get called for all combinations, and if I'm only handling the
> post-promote combination, all others I need to simply return
> OCF_SUCCESS, right?
> 
> The remaining question I have is, does adding notify to the <actions>
> meta-data and configuring the notify operation via the Add Operation
> on the GUI "activate" heartbeat's usage of notify? Or are there any
> other parameters/flags I need to set to enable using notify? I seem to
> remember there was mention of some configuration items for using
> notify.
> 
> Thanks,
> Doug
> 
> On Tue, 2007-03-27 at 23:14 +0200, Lars Marowsky-Bree wrote: 
> 
> > On 2007-03-22T13:24:02, Doug Knight <dknight at wsi.com> wrote:
> > 
> > Hi,
> > 
> > I've been out a bit myself but now want to answer this.
> > 
> > > Hi Alan,
> > > I took a look at the drbd OCF script's notify function, and the online
> > > documentation. I believe there is one circumstance where I need to make
> > > use of the pre/post notify. 
> > 
> > The reason why drbd calls update_prefs (ie, crm_master) in the
> > post(-start) notification, and not within start itself, is that by that
> > time, start will have been completed on all (one or both) nodes.
> > 
> > That means that by that time, it's safe to figure out which side is
> > preferable for becoming master.
> > 
> > 
> > > The last step in my development/testing has
> > > to do with several steps I take to prepare the server that was primary
> > > and is now becoming standby. First, the primary gets demoted, right?
> > 
> > Yes.
> > 
> > > Then the secondary gets promoted. The problem I have is that part of the
> > > process of preparing the new standby requires that the new active server
> > > process is up and accessible. If the demote has to complete before the
> > > promote can begin, I cannot do the rsync in the demote, because the
> > > promote hasn't started and placed the new primary in an accessible
> > > state. 
> > 
> > That seems to be true for your scenario, yes.
> > 
> > > So, if I understand the notify function, then I need a "post" process
> > > section that looks for the master going "active" and accessible, so I
> > > can do the rsync and start up the new standby, right?
> > 
> > That you could do. The instances will get a post-promote notification,
> > which could do what you want.
> > 
> > > Can you expand a little on the notify processing? The web page just
> > > lists the variables involved, and the drbd OCF script only makes use
> > > of a few of them, and I need a more detailed explanation of how and
> > > when they are used. 
> > 
> > Well, you get a pre-notification before start/stop/promote/demote happen
> > anywhere and a post-notification after they have completed everywhere.
> > That's basically the gist of it.
> > 
> > Does that make it clearer, or do you have a specific question?
> > 
> > 
> > Sincerely,
> >     Lars
> > 
> 
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.community.tummy.com/pipermail/linux-ha-dev/attachments/20070328/7e9975c0/attachment.html


More information about the Linux-HA-Dev mailing list