10.3.6. Multi-state Constraints

In most cases, multi-state resources will have a single copy on each active cluster node. If this is not the case, you can indicate which nodes the cluster should preferentially assign copies to with resource location constraints. These constraints are written no differently from those for primitive resources except that the master’s id is used.

When considering multi-state resources in constraints, for most purposes it is sufficient to treat them as clones. The exception is that the first-action and/or then-action fields for ordering constraints may be set to promote or demote to constrain the master role, and colocation constraints may contain rsc-role and/or with-rsc-role fields.

Table 10.7. Additional colocation constraint options for multi-state resources

Field	Default	Description
`rsc-role`	Started	An additional attribute of colocation constraints that specifies the role that `rsc` must be in. Allowed values: `Started`, `Master`, `Slave`.
`with-rsc-role`	Started	An additional attribute of colocation constraints that specifies the role that `with-rsc` must be in. Allowed values: `Started`, `Master`, `Slave`.

Example 10.8. Constraints involving multi-state resources

<constraints>
   <rsc_location id="db-prefers-node1" rsc="database" node="node1" score="500"/>
   <rsc_colocation id="backup-with-db-slave" rsc="backup"
     with-rsc="database" with-rsc-role="Slave"/>
   <rsc_colocation id="myapp-with-db-master" rsc="myApp"
     with-rsc="database" with-rsc-role="Master"/>
   <rsc_order id="start-db-before-backup" first="database" then="backup"/>
   <rsc_order id="promote-db-then-app" first="database" first-action="promote"
     then="myApp" then-action="start"/>
</constraints>

In the example above, myApp will wait until one of the database copies has been started and promoted to master before being started itself on the same node. Only if no copies can be promoted will myApp be prevented from being active. Additionally, the cluster will wait for myApp to be stopped before demoting the database.

Colocation of a primitive or group resource with a multi-state resource means that it can run on any machine with an active copy of the multi-state resource that has the specified role (master or slave). In the example above, the cluster will choose a location based on where database is running as a master, and if there are multiple master instances it will also factor in myApp's own location preferences when deciding which location to choose.

Colocation with regular clones and other multi-state resources is also possible. In such cases, the set of allowed locations for the rsc clone is (after role filtering) limited to nodes on which the with-rsc multi-state resource is (or will be) in the specified role. Placement is then performed as normal.

10.3.6.1. Using Multi-state Resources in Colocation Sets

Table 10.8. Additional colocation set options relevant to multi-state resources

Field	Default	Description
`role`	Started	The role that all members of the set must be in. Allowed values: `Started`, `Master`, `Slave`.

In the following example B's master must be located on the same node as A's master. Additionally resources C and D must be located on the same node as A's and B's masters.

Example 10.9. Colocate C and D with A’s and B’s master instances

<constraints>
    <rsc_colocation id="coloc-1" score="INFINITY" >
      <resource_set id="colocated-set-example-1" sequential="true" role="Master">
        <resource_ref id="A"/>
        <resource_ref id="B"/>
      </resource_set>
      <resource_set id="colocated-set-example-2" sequential="true">
        <resource_ref id="C"/>
        <resource_ref id="D"/>
      </resource_set>
    </rsc_colocation>
</constraints>