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/
