2012/10/25 Dejan Muhamedagic <de...@suse.de>: > 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 :)
It makes no sense to using different clones. Pgsql only uses instance numbers for changing master score on other nodes. Master score needs it on Pacemaker 1.0.x regardless of globally-unique. > >> 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. I will improve it. > >> 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 Thanks, Takatoshi MATSUO _______________________________________________________ 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/
