10.3.6. Multi-state Constraints

In most cases, a 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 to those for regular 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 when the rsc-role and/or with-rsc-role fields (for colocation constraints) and first-action and/or then-action fields (for ordering constraints) are used.

Table 10.7. Additional constraint options relevant to multi-state resources

Field	Description
`rsc-role`	An additional attribute of colocation constraints that specifies the role that `rsc` must be in. Allowed values: Started, `Master`, `Slave`.
`with-rsc-role`	An additional attribute of colocation constraints that specifies the role that `with-rsc` must be in. Allowed values: Started, `Master`, `Slave`.
`first-action`	An additional attribute of ordering constraints that specifies the action that the `first` resource must complete before executing the specified action for the `then` resource. Allowed values: start, `stop`, `promote`, `demote`.
`then-action`	An additional attribute of ordering constraints that specifies the action that the `then` resource can only execute after the `first-action` on the `first` resource has completed. Allowed values: `start`, `stop`, `promote`, `demote`. Defaults to the value (specified or implied) of `first-action`.

In the example below, myApp will wait until one of the database copies has been started and promoted to master before being started itself. Only if no copies can be promoted will apache-stats be prevented from being active. Additionally, the database will wait for myApp to be stopped before it is demoted.

Example 10.8. Example 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>

Colocation of a regular (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 is in the specified state (Master or Slave). In the example, 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. Allocation is then performed as-per-normal.