There is a failure scenario we need to account for that has been brought to my attention. If the SST sync takes longer than the promotion op's timeout value, the promotion will fail and pacemaker will in turn stop the mysqld daemon in an attempt to recover the resource.  Users with large databases could experience this with the current default timeout settings.

We don't want this to happen. If the SST is still in progress, having pacemaker stop the mysqld instance could corrupt the database on the local node.

There's a simple fix for this

1. set the on-fail=block option for the galera resources promote operation.
2. Be very generous when setting the promotion timeout. By default promote gets 2 minutes. Maybe we should consider something much larger like 5 minutes.
3. Be certain we are promoting the instances in series, not parallel by using the ordered=true option. This will prevent galera instances from potentially waiting on each other to sync with the same donor node.

Example: 
pcs resource create db galera enable_creation=true wsrep_cluster_address=gcom,://node1,node2,node3 meta master-max=3 ordered=true op promote timeout=300s on-fail=block --master

Now , if the galera instance does fail during the promote Pacemaker will not attempt to recover the resource (which is what we want). If this failure is experienced, after verifying the failed node's database is not still in the process of syncing, the user should double the galera promotion timeout value and then execute resource cleanup to remove the failure which will allow pacemaker to manage the database again.

-- Vossel

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2014-1957.html