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/
