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 On Wed, 2007-03-21 at 10:09 +0100, Andrew Beekhof wrote: > On 3/20/07, Doug Knight <[EMAIL PROTECTED]> wrote: > > > > Hi Alan, > > I've had some time to try to implement the OCF script for the PostgreSQL > > WAL file forwarding configuration, and I still am having some issues. The > > main issue is how do I set up an OCF script that allows the process to run > > on both servers, one process in a "starting" mode ingesting transferred WAL > > files, the other in an "accessible" mode allowing database access and > > forwarding WAL files to the standby (right now the different states are > > determined within the OCF script by looking for the existence of a > > recovery.conf file, which indicates the "starting", standby side)? What I'm > > trying to figure out is how to tell HA that it needs to start the standby > > process and monitor it. > > > > I've started looking at the multi-state configurations, but the > > documentation isn't completely clear. Can you expand on it? I'd like > > something similar to the answers you gave for the monitor, stop, and start > > functions (when do they/can they get invoked, on which node, etc). One > > specific area of the multi-state config I have a question about is how to > > tell HA which server has the master role when first starting up the > > resource. Any additional info would be great. > > have a look at the drbd and Stateful agents: > > http://hg.beekhof.net/lha/crm-dev/file/be220f2e9b40/resources/OCF/Stateful.in > > but first read: > http://linux-ha.org/v2/Concepts/MultiState > > in particular, section 6.1 > > > > > Thanks, > > Doug > > > > > > > > > > On Wed, 2007-03-14 at 19:59 -0600, Alan Robertson wrote: > > Doug Knight wrote: > > > Yes, Thanks Alan. Let me digest it, and walk through my OCF script. I'll > > > see if I have any other questions after that. > > > > > > Thanks for getting back to me. > > > > > > Doug > > > > > > On Wed, 2007-03-14 at 11:41 -0600, Alan Robertson wrote: > > >> Doug Knight wrote: > > >> > Hi All, > > >> > I currently am running a two node cluster (host1 and host2) with > > version > > >> > 2.0.8. I have a resource defined with a place constraint of "#uname eq > > >> > host1", so that it will start on host1 (using an OCF RA script, > > >> > including all of the required methods). The resource itself has > > >> > target_role set to "stopped". > > >> > > > >> > Question 1: Is the monitor method called regularly on both nodes to > > make > > >> > sure the resource is not running? > > >> > > >> No. It is called on every node when we first start up (we call it a > > >> probe operation). If you ask us to, we will run it periodically to > > >> ensure that a running copy continues to run. > > >> > > >> You can also manually request to run this initial probe again to catch > > >> errors made by system administrators (but I don't know of anyone who > > >> does that). > > >> > > >> > > >> > Next, I change the target_role to "started" (i.e. I use the GUI and > > >> > click the start button). > > >> [Better yet, use the "outline" start button] > > >> > > >> > Question 2: What is the order of OCF methods called to bring up the > > >> > resource? Is Monitor called before Start on host1? Does Stop and/or > > >> > Monitor ever get called on host2? > > >> > > >> Monitor gets called when we first start up on every node. > > >> It also get called repeatedly on any node that we think is running it -- > > >> if you ask us to monitor the resource. > > >> > > >> > Resource is up and running on host1, and I decide to move the resource > > >> > to host2. I click the constraint and change it to "#uname eq host2". > > The > > >> > resource stops on host1 and starts on host2. > > >> > > > >> > Question 3: Same idea, what are the sequence of method calls to migrate > > >> > the resource from host1 to host2? > > >> > > >> In the past... > > >> monitor every resource on every node once to see what's already > > >> running > > >> start on "some node" > > >> monitor periodically on "some node" (if requested) > > >> > > >> Request to move resource arrives... > > >> stop monitoring on "some node" (if it had been requested) > > >> stop resource on "some node" > > >> start resource on "some other" node > > >> monitor periodically on "some other node" (if requested) > > >> > > >> > I'm trying to thoroughly understand the sequence of events that occurs > > >> > for each phase in support of the Postgres WAL file forwarding > > >> > configuration I posted last week ("[Linux-HA] Two node cluster with > > >> > Postgres in WAL file fwding mode", started March 1). > > > > > > Let me offer this caveat: > > > > Monitor might be called at any time. > > > > Stop should work at any time, > > and succeed harmlessly if it's already stopped. > > > > Start should work at any time, > > and succeed harmlessly if it's already started. > > > > http://www.linux-ha.org/OCFResourceAgent gives more > > details. > > > > > > > > _______________________________________________________ > > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > > Home Page: http://linux-ha.org/ > > > > > _______________________________________________________ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ >
_______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
