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 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? 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.
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? 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. Thanks, Doug On Wed, 2007-03-21 at 19:13 -0600, Alan Robertson wrote: > Doug Knight wrote: > > Hi Andrew, > > I had just started reviewing both of thes scripts, and reviewed the > > Multistate and clone resource pages on the web site. It looks like > > multistate is how I need to handle it, but a couple of questions first. > > > > 1. I noticed that the write-up says the resource must come up on each of > > the servers in "shadow" mode first, then one gets promoted. Does this > > imply a "start" on both servers, and the OCF start function determining > > which server is active vs shadow (I'm picturing a check in the OCF > > script to determine postgresql standby mode = shadow/crm_master value > > low, and postgresql active mode = active/crm_master value high), then a > > promote to the active server? > > > > 2. I noticed that the drbd OCF script contains a "notify" function, > > where the Stateful OCF script does not. The notify function looks to be > > where the important actions are taken (calling drbd_start_phase_2, > > pre/post, etc). Is the notify function necessary, or is it sufficient in > > my case to handle it through the start|stop|promote|demote functions? > > > > Thanks for your help, > > Doug > > Andrew's out for a while. > > The start function starts you up in slave/secondary mode. All resources > initially start up in "slave" mode. > > A set of servers is chosen to run the resources on (it might be one, > two, the whole set, etc. depending on clone_max and clone_node_max and > the usual constraints). > > They are started on the selected nodes using "start" > > During the start operation, you are given the chance to declare yourself > ready to become master or not by using the crm_master command line tool. > > I believe that your resource can run that command any time they like - > for example at a monitor operation... But, it is mandatory that they > run it when they first start up. > > After this, heartbeat will try and promote as many of these resources as > is consistent with its configured properties, and the crm_master > commands that were run. > > The notify command tells you when your peers come and go. Do you need > to take actions if you know this? > > If so, then you need to implement the notify actions... > > >
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
