Download MySQL Utilities - Oracle Documentation

Setting up and testing your system
# Load the Pacemaker Cluster Resource Manager
name: pacemaker
ver: 1
}
Change the /etc/default/corosync file as follows:
# start corosync at boot [yes|no]
START=yes
To avoid any mismatches, the configuration file can be copied across by using these commands on host1:
shell> scp /etc/corosync/corosync.conf host2:/etc/corosync/corosync.conf
shell> scp /etc/corosync/service.d/pcmk host2:/etc/corosync/service.d/pcmk
shell> scp /etc/default/corosync host2:/etc/default/corosync
Start Corosync on both hosts using:
shell> /etc/init.d/corosync start
Run tpcdump to check whether Corosync is working or not:
shell> tcpdump -i eth0 -n port 5405
To start the Pacemaker on host1, execute the following command:
shell> /etc/init.d/pacemaker start
Run Pacemaker's cluster resource monitoring command on host1 to view the status of the cluster:
shell> crm_mon --one-shot -V
As we are configuring a cluster made up of just 2 hosts, when one host fails (or loses contact with the
other) there is no node majority (quorum) left and so by default the surviving node (or both if they are still
running but isolated from each other) would be shut down by Pacemaker. This is not the desired behavior
as it does not offer High Availability and so that default should be overridden (we will later add an extra
behavior whereby each node will shut itself down if it cannot ping a 3 node that is external to the cluster,
thus preventing a split brain situation):
[root@host1]# crm configure property no-quorum-policy=ignore
We turn STONITH (Shoot The Other Node In The Head) off as this solution will rely on each node shutting
itself down in the event that it loses connectivity with the independent host:
[root@host1]# crm configure property stonith-enabled=false
Roughly speaking, STONITH refers to one node trying to kill another in the even that it believes the other
has partially failed and should be stopped in order to avoid any risk of a split-brain scenario. To prevent a
healthy resource from being moved around the cluster when a node is brought back on-line, Pacemaker
has the concept of resource stickiness which controls how much a service prefers to stay running where it
is.
253