9.2. Multistate Resources: Resources That Have Multiple Modes Multistate resources are a specialization of Clone resources. They allow the instances to be in one of two operating modes; these are called Master and Slave . The names of the modes do not have specific meanings, except for the limitation that when an instance is started, it must come up in the Slave state. You can create a resource as a master/slave clone with the following single command. The name of the master/slave clone will be resource_id -master . Note For Red Hat Enterprise Linux release 7.3 and earlier, use the following format to create a master/slave clone. Alternately, you can create a master/slave resource from a previously-created resource or resource group with the following command: When you use this command, you can specify a name for the master/slave clone. If you do not specify a name, the name of the master/slave clone will be resource_id -master or group_name -master . For information on resource options, see Section 6.1, "Resource Creation" . Table 9.2, "Properties of a Multistate Resource" describes the options you can specify for a multistate resource. Table 9.2. Properties of a Multistate Resource Field Description id Your name for the multistate resource priority , target-role , is-managed See Table 6.3, "Resource Meta Options" . clone-max , clone-node-max , notify , globally-unique , ordered , interleave See Table 9.1, "Resource Clone Options" . master-max How many copies of the resource can be promoted to master status; default 1. master-node-max How many copies of the resource can be promoted to master status on a single node; default 1. 9.2.1. Monitoring Multi-State Resources To add a monitoring operation for the master resource only, you can add an additional monitor operation to the resource. Note, however, that every monitor operation on a resource must have a different interval. The following example configures a monitor operation with an interval of 11 seconds on the master resource for ms_resource . This monitor operation is in addition to the default monitor operation with the default monitor interval of 10 seconds. 9.2.2. Multistate Constraints In most cases, a multistate 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 than those for regular resources. For information on resource location constraints, see Section 7.1, "Location Constraints" . You can create a colocation constraint which specifies whether the resources are master or slave resources. The following command creates a resource colocation constraint. For information on colocation constraints, see Section 7.3, "Colocation of Resources" . When configuring an ordering constraint that includes multistate resources, one of the actions that you can specify for the resources is promote , indicating that the resource be promoted from slave to master. Additionally, you can specify an action of demote , indicated that the resource be demoted from master to slave. The command for configuring an order constraint is as follows. For information on resource order constraints, see Section 7.2, "Order Constraints" . 9.2.3. Multistate Stickiness To achieve a stable allocation pattern, multistate resources are slightly sticky by default. If no value for resource-stickiness is provided, the multistate resource will use a value of 1. Being a small value, it causes minimal disturbance to the score calculations of other resources but is enough to prevent Pacemaker from needlessly moving copies around the cluster.

Commands:
pcs resource create resource_id standard:provider:type | type [ resource options ] master [ master_options ]
pcs resource create resource_id standard:provider:type | type [ resource options ] --master [meta master_options ]
pcs resource master master/slave_name resource_id|group_name [ master_options ]
pcs resource op add ms_resource interval=11s role=Master
pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [ score ] [ options ]
pcs constraint order [ action ] resource_id then [ action ] resource_id [ options ]