I don't understand why a problem with a resource causes other resources above it in the dependency stack (or on the same level with it) to fail over.
My dependency stack is: drbd -> filesystem -> floating_ip -> Azure virtual IP | -> MySQL_instance_1 -> MySQL_instance_2 Note that the MySQL instances are dependent on the floating IP, but not on each other. However, if one of the MySQL instances has a problem that causes it to go into a FAIL status, the whole cluster fails over. Or if the Azure virtual IP resource has a problem and I need to run a cleanup, the whole cluster fails over. Here's what my resources look like... [root@001db01b mysql]# pcs status Cluster name: 001db01ab Stack: corosync Current DC: 001db01b (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum Last updated: Mon Aug 6 12:52:44 2018 Last change: Mon Aug 6 12:18:38 2018 by root via cibadmin on 001db01a 2 nodes configured 11 resources configured Online: [ 001db01a 001db01b ] Full list of resources: p_vip_clust01 (ocf::heartbeat:IPaddr2): Started 001db01b p_azip_clust01 (ocf::heartbeat:AZaddr2): Started 001db01b Master/Slave Set: ms_drbd0 [p_drbd0] Masters: [ 001db01b ] Slaves: [ 001db01a ] Master/Slave Set: ms_drbd1 [p_drbd1] Masters: [ 001db01a ] Slaves: [ 001db01b ] p_fs_clust01 (ocf::heartbeat:Filesystem): Started 001db01b p_fs_clust02 (ocf::heartbeat:Filesystem): Started 001db01a p_vip_clust02 (ocf::heartbeat:IPaddr2): Started 001db01a p_azip_clust02 (ocf::heartbeat:AZaddr2): Started 001db01a p_mysql_001 (lsb:mysql_001): Started 001db01b Daemon Status: corosync: active/enabled pacemaker: active/enabled Here's what my constraints look like... [root@001db01b mysql]# pcs constraint --full Location Constraints: Ordering Constraints: promote ms_drbd0 then start p_fs_clust01 (kind:Mandatory) (id:order-ms_drbd0-p_fs_clust01-mandatory) promote ms_drbd1 then start p_fs_clust02 (kind:Mandatory) (id:order-ms_drbd1-p_fs_clust02-mandatory) start p_fs_clust01 then start p_vip_clust01 (kind:Mandatory) (id:order-p_fs_clust01-p_vip_clust01-mandatory) start p_vip_clust01 then start p_azip_clust01 (kind:Mandatory) (id:order-p_vip_clust01-p_azip_clust01-mandatory) start p_fs_clust02 then start p_vip_clust02 (kind:Mandatory) (id:order-p_fs_clust02-p_vip_clust02-mandatory) start p_vip_clust02 then start p_azip_clust02 (kind:Mandatory) (id:order-p_vip_clust02-p_azip_clust02-mandatory) start p_vip_clust01 then start p_mysql_001 (kind:Mandatory) (id:order-p_vip_clust01-p_mysql_001-mandatory) Colocation Constraints: p_azip_clust01 with p_vip_clust01 (score:INFINITY) (id:colocation-p_azip_clust01-p_vip_clust01-INFINITY) p_fs_clust01 with ms_drbd0 (score:INFINITY) (with-rsc-role:Master) (id:colocation-p_fs_clust01-ms_drbd0-INFINITY) p_fs_clust02 with ms_drbd1 (score:INFINITY) (with-rsc-role:Master) (id:colocation-p_fs_clust02-ms_drbd1-INFINITY) p_vip_clust01 with p_fs_clust01 (score:INFINITY) (id:colocation-p_vip_clust01-p_fs_clust01-INFINITY) p_vip_clust02 with p_fs_clust02 (score:INFINITY) (id:colocation-p_vip_clust02-p_fs_clust02-INFINITY) p_azip_clust02 with p_vip_clust02 (score:INFINITY) (id:colocation-p_azip_clust02-p_vip_clust02-INFINITY) p_mysql_001 with p_vip_clust01 (score:INFINITY) (id:colocation-p_mysql_001-p_vip_clust01-INFINITY) Ticket Constraints: _______________________________________________ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org