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
