On Thu, 2011-02-10 at 13:07 +0100, Dejan Muhamedagic wrote: > On Wed, Feb 09, 2011 at 07:38:49PM +0100, Holger Teutsch wrote: > > Hi, > > please find enclosed the revised version. > > > > -holger > > > > On Wed, 2011-02-09 at 14:03 +0100, Dejan Muhamedagic wrote: > > > Hi, > > > > > > > > Please find below some comments. > [...] > > > > # > > > > # maintain the fal (first active log) attribute > > > > # db2_fal_attrib DB {set val|get|delete} > > > > # > > > > db2_fal_attrib() { > > > > local db=$1 > > > > local attr > > > > > > > > attr=db2hadr_${instance}_${db}_fal > > > > > > > > case "$2" in > > > > set) > > > > crm_attribute -t crm_config -n $attr -v "$3" > > > > > > Hmm, this is an attribute which should be on the master > > > right? Using crm_config for that looks wrong. I think > > > that it should go into the node status. > > > > No, it is an attribute that communicates the log position from the > > Master node to a restarting slave node. > > crm_config is for static configuration and actually for cluster > wide properties which are to be interpreted by the CRM. Now, I > cannot say how does db2 promote/demote work, but isn't it > possible to keep that as a dynamic node attribute? I think that > you should get information through the environment about which > node is currently the master. Then, the slave can read whichever > attribute it needs from that node's attributes. Can somebody with > more experience in ms resources confirm? >
I see your point. I looked at the env during a start operation. Unfortunately no indication about the current master. I assume it can be done with notifications but these are asynchronous to the start operation. That means stuffing the info into a file, maintaining this, race conditions etc. That would be a major reengineering + difficult Q/A. > > > Also, since it goes to eval below, better add single quotes around > > > /HADR_PEER_WINDOW/ {printf "HADR_PEER_WINDOW='%s'\n" ... > > > > I've put it in but the output is *very* expected (hopefully the DB is > > really DB2 8-). > > Yes, we can hope, but no telling when another idle engineer is > going to change the output :) IBM is extremely stable in this regard 8-) > > IIRC, you still didn't reply about adding the hadr parameter. > This is the last I wrote on the matter elsewhere in this > jumbo-thread: > > HADR is a very different beast from non-HADR db, right? Why not > then add the "hadr" boolean parameter and use that instead of > checking if the resource has been configured as multi-state? > Then the RA can complain if the resource is not ms. And in the > configuration it is going to be obvious that this is a HADR > instance. > > In short, the idea is to have the user state their intentions > clearly. What's your opinion? I like to stay with the current setup. Even without cluster setting up HADR for DB2 is a major effort. I can't see any use of a m/s resource for db2 outside of HADR. On the other hand managing HADR instances outside of a m/s setup is not sensible either. An additional parameter stating "Yes, I acknowledge that I want an HADR environment managed by pacemaker" looks redundant to me. The agent just "picks up" the DB2 configuration and manages it. Best regards Holger _______________________________________________________ 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/