On Thu, Oct 25, 2012 at 06:09:38AM -0700, Lars Ellenberg wrote: > On Thu, Oct 25, 2012 at 03:38:47AM -0700, Takatoshi MATSUO wrote: > > Usually, we use "crm_master" command instead of "crm_attribute" to change > > master score in RA. > > But PostgreSQL's slave can't get own replication status, so Master changes > > Slave's master-score > > using instance number on Pacemaker 1.0.x . > > This probably is not ordinary usage. > > > > > Would the existing resource agent work with globally-unique=true ? > > > > I don't know it works with true. > > I use it with false and it dosen't need true. > > I suggested that you actually should use globally-unique clones, > as in that case you still get those instance numbers...
Does using different clones make sense in pgsql? What is to be different between them? Or would it be just for the sake of getting instance numbers? If so, then it somehow looks wrong to me :) > But thinking about it once more, I'm not so sure anymore. > > Correct me where I'm wrong. > > This is about the master score. > In case the Master instance fails, we preferably want to promote the > slave instance that is as close as possible to the Master. > We only know which *node* was "best" at the last monitoring interval, > which may be "good enough". > > We need to then change the master score for *all possible instances*, > for all nodes, accordingly. > > Which is what that loop did. > (I think skipping the "current" instance is actually a bug; > If pacemaker relabeles things in a "bad way", you may hit it). > > Now, with pacemaker 1.1.8, all instances become "equal" > (for anonymous clones, aka globally-unique=false), > and we only need to set the score on the resource-id, > not for all resource-id:instance combinations. OK. > Which is great. After all, the master score in this case is attached to > the node (or, the data set accessible from that node), and not to the > (arbitrary, potentially relabeled "anytime") instance number pacemaker > assigned to the clone instance running on that node. > > > And that is exactly what your patch does: > * detect if a version of pacemaker is in use that attaches the instance > number to the resource id > * if so, do the loop on all possible instance numbers as before > * if not, only set the master score on the resource-id > > > Is my understanding correct? > Then I think you patch is good. Yes, the patch seems good then. Though there is quite a bit of code repetition. The "set attribute part" should be moved to an extra function. > Still, other resource agents that use master scores (or any other > attributes that reference instance numbers of anonymous clones) > need to be reviewed. > > Though this "I'll set scores for other instances, not only myself" > logic is unique to pgsql, so most other resource agents should "just > work" with whatever is present in the environment, they typically treat > the $OCF_RESOURCE_INSTANCE as opaque. Seems like no other RA uses instance numbers. However, quite a few use OCF_RESOURCE_INSTANCE which, in case of clone/ms resources, may potentially lead to unpredictable results on upgrade to 1.1.8. > Thanks, > Lars Cheers, Dejan _______________________________________________________ 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/
