On 3/28/07, Doug Knight <[EMAIL PROTECTED]> wrote:

 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?

both


 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 <[EMAIL PROTECTED]> 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: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to