[Pacemaker] [Question] About control of colocation.(master-slave with primitive)

Andrew Beekhof andrew at beekhof.net
Thu May 15 00:16:47 UTC 2014


On 15 May 2014, at 9:57 am, renayama19661014 at ybb.ne.jp wrote:

> Hi Andrew,
> 
> Thank you for comments.
> 
>>> We do not want to be promoted to Master in the node that primitive resource does not start.
>>> Is there the setting of colocation and order which are not promoted to Master of the Master node?
>> 
>> Your config looks reasonable... almost certainly a bug in the PE.
>> Do you happen to have the relevant pengine input file available?
> 
> Really?

I would expect that:

  colocation rsc_colocation-master-1 INFINITY: msPostgresql:Master A-master

would only promote msPostgresql on a node where A-master was running.

Is that not what you were wanting?


> It was like right handling of PE as far as I confirmed a source code of PM1.1.
> I register this problem with Bugzilla and contact you.
> 
> Best Regards,
> Hideo Yamauchi.
> 
> --- On Wed, 2014/5/14, Andrew Beekhof <andrew at beekhof.net> wrote:
> 
>> 
>> On 13 May 2014, at 3:14 pm, renayama19661014 at ybb.ne.jp wrote:
>> 
>>> Hi All,
>>> 
>>> We assume special resource constitution.
>>> Master of master-slave depends on primitive resource for the constitution.
>>> 
>>> We performed the setting that Master stopped becoming it in Slave node experimentally.
>>> 
>>> 
>>>    location rsc_location-msStateful-1 msPostgresql \
>>>         rule $role="master" 200: #uname eq srv01 \
>>>         rule $role="master" -INFINITY: #uname eq srv02
>>> 
>>> The Master resource depends on the primitive resource.
>>> 
>>>    colocation rsc_colocation-master-1 INFINITY: msPostgresql:Master A-master
>>> 
>>> 
>>> Step1) Start Slave node.
>>> -----------------------------------------------------------
>>> [root at srv02 ~]# crm_mon -1 -Af
>>> Last updated: Tue May 13 22:28:12 2014
>>> Last change: Tue May 13 22:28:07 2014
>>> Stack: corosync
>>> Current DC: srv02 (3232238190) - partition WITHOUT quorum
>>> Version: 1.1.11-f0f09b8
>>> 1 Nodes configured
>>> 3 Resources configured
>>> 
>>> 
>>> Online: [ srv02 ]
>>> 
>>> A-master     (ocf::heartbeat:Dummy): Started srv02 
>>> Master/Slave Set: msPostgresql [pgsql]
>>>      Slaves: [ srv02 ]
>>> 
>>> Node Attributes:
>>> * Node srv02:
>>>     + master-pgsql                      : 5         
>>> 
>>> Migration summary:
>>> * Node srv02: 
>>> -----------------------------------------------------------
>>> 
>>> Step2) Start Master node.
>>> -----------------------------------------------------------
>>> [root at srv02 ~]# crm_mon -1 -Af
>>> Last updated: Tue May 13 22:33:39 2014
>>> Last change: Tue May 13 22:28:07 2014
>>> Stack: corosync
>>> Current DC: srv02 (3232238190) - partition with quorum
>>> Version: 1.1.11-f0f09b8
>>> 2 Nodes configured
>>> 3 Resources configured
>>> 
>>> 
>>> Online: [ srv01 srv02 ]
>>> 
>>> A-master     (ocf::heartbeat:Dummy): Started srv02 
>>> Master/Slave Set: msPostgresql [pgsql]
>>>      Masters: [ srv01 ]
>>>      Slaves: [ srv02 ]
>>> 
>>> Node Attributes:
>>> * Node srv01:
>>>     + master-pgsql                      : 10        
>>> * Node srv02:
>>>     + master-pgsql                      : 5         
>>> 
>>> Migration summary:
>>> * Node srv02: 
>>> * Node srv01: 
>>> -----------------------------------------------------------
>>> 
>>> * The Master node that primitive node does not start becomes Master.
>>> 
>>> 
>>> We do not want to be promoted to Master in the node that primitive resource does not start.
>>> Is there the setting of colocation and order which are not promoted to Master of the Master node?
>> 
>> Your config looks reasonable... almost certainly a bug in the PE.
>> Do you happen to have the relevant pengine input file available?
>> 
>>> 
>>> I think that one method includes the next method.
>>>   * I handle it to update an attribute when primitive resource starts.
>>>   * I write an attribute in the condition to be promoted to Master.
>>> 
>>> 
>>> In addition, we are often confused about control of colotaion and order.
>>> It is in particular the control between primitive/group resource and clone/master-slave resources.
>>> Will you describe detailed contents in a document?
>>> 
>>> 
>>> Best Regards,
>>> Hideo Yamauchi.
>>> 
>>> _______________________________________________
>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>> 
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>> Bugs: http://bugs.clusterlabs.org
>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140515/9f0b2c9e/attachment-0004.sig>


More information about the Pacemaker mailing list