Hi Phillip,
Thank you for comment.
However, the result was the same even if I used the Group resource.
(snip)
<group id="GrpvipCheck"> <primitive class="ocf" id="vipCheck"
provider="pacemaker" type="Dummy"> <instance_attributes
id="vipCheck-instance_attributes"> </instance_attributes>
<operations> <op id="vipCheck-start-0s" interval="0s" name="start"
on-fail="restart" start-delay="4s" timeout="90s"/> </operations>
</primitive>
</group>
(snip)
<rsc_order first="GrpvipCheck" first-action="start" id="rsc_order-7"
score="INFINITY" then="msPostgresql" then-action="promote"/>
(snip)
============
Last updated: Mon Jul 2 17:56:27 2012
Stack: Heartbeat
Current DC: rh62-test1 (6d534d4e-a3a1-4a92-86c7-eadf6c2f7570) - partition with
quorum
Version: 1.0.12-unknown
1 Nodes configured, unknown expected votes
2 Resources configured.
============
Online: [ rh62-test1 ]
Master/Slave Set: msPostgresql
Masters: [ rh62-test1 ]
Stopped: [ postgresql:1 ]
Migration summary:
* Node rh62-test1:
vipCheck: migration-threshold=1 fail-count=1000000
Failed actions:
vipCheck_start_0 (node=rh62-test1, call=4, rc=1, status=complete): unknown
error
Best Regards,
Hideo Yamauchi.
--- On Fri, 2012/6/29, Phillip Frost <[email protected]> wrote:
>
> On Jun 28, 2012, at 10:26 PM, [email protected] wrote:
>
> >> We set order limitation as follows.
> >
> > <rsc_colocation id="rsc_colocation-7" rsc="vipCheck" score="INFINITY"
> >with-rsc="msPostgresql" with-rsc-role="Master"/>
> > <rsc_order first="vipCheck" first-action="start" id="rsc_order-7"
> >score="INFINITY" then="msPostgresql" then-action="promote"/>
> >
> >> However, promote was carried out even if primitvei resource caused start
> >> trouble.
> >>
> >> Online: [ rh62-test1 ]
> >>
> >> Master/Slave Set: msPostgresql
> >> Masters: [ rh62-test1 ]
> >> Stopped: [ postgresql:1 ]
> >>
> >> Migration summary:
> >> * Node rh62-test1:
> >> vipCheck: migration-threshold=1 fail-count=1000000
> >>
> >> Failed actions:
> >> vipCheck_start_0 (node=rh62-test1, call=4, rc=1, status=complete):
> >>unknown error
>
> What happens if you reverse the order of the of the colocation constraint?
> You've told pacemaker to decide where to put msPostgresql:Master first, and
> if it can't run that, then don't run vipCheck, but to start them in the
> opposite order. I'm not sure an order constraint will prevent one resource
> from running if another fails to start, but a colocation constraint will, if
> you get it in the right order.
>
> You could also use a resource group, which combines colocation and order
> constraints in the order you'd expect.
>
_______________________________________________
Pacemaker mailing list: [email protected]
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
