On Thu, Feb 10, 2011 at 04:39:20PM +0100, Holger Teutsch wrote:
> 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.
Yes, obviously. Can some m/s expert please help here? Thanks!
> > > > 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-)
Everything changes, even IBM ;-)
> > 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.
OK.
Cheers,
Dejan
> 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/
_______________________________________________________
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/
