使用heartbeat实现mysql高可用集群
clients
|||
vip <----浮动IP
|
|-----------------|
MySQL1 MySQL2 <---- 这两个节点组成了HA集群
|---------|-------|
存储
只有活动节点才挂载存储，才使用读写存储上的数据，备用节点不去挂载使用。
只要使用到共享存储的HA集群，都必须注意避免的脑裂现象，根本避免闹裂现象的解决方法是使用电源设备。
如果没有电源设备，可以使用“双心跳”降低脑裂发生的机率。
node2.upl.com
eth0 1.1.1.129 virbr1
eth1 2.2.2.129 virbr2
node3.upl.com
eth0 1.1.1.130 virbr1
eth1 2.2.2.130 virbr2
存储
eth0 2.2.2.128 virbr2
一、部署iscsi存储端
二、MySQL节点发现、连接iscsi目标
建议：开机自动连接iscsi目标。使用udev生成设备的软连接。
文件系统：gfs2 或者 ext3
# mkfs.ext3 /dev/iscsi/webroot/part1
如果使用gfs2:
配置存储集群system-config-cluster,同步配置
启动cman服务，作用：把集群关系建立起来。
格式化gfs2
两个节点同时挂载，测试集群文件系统。
三、部署mysql服务
1）只需要其中一个节点挂载存储并且初始化数据库目录
2）分别测试mysql服务是否工作正常。
测试完毕之后，手工停止所有资源的使用。
停止mysqld服务，取消挂载。
四、部署heartbeat
1、ha.cf
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 12
warntime 6
initdead 60
udpport 694
ucast eth0 1.1.1.130
ucast eth1 2.2.2.130 <----双心跳
auto_failback on
node node2.upl.com
node node3.upl.com
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster
ping 1.1.1.1 <--- 辅助网络故障的判断。如果某个节点接受不到对方的心跳，它会尝试与设定ping节点通讯，如果ping不通，它会结果告诉其他节点，把ping得同的数量和其他节点对比，如果自己的数量比别人少，说明网络故障是发生在自身，就会把资源主动让给其他节点。
2、haresources
资源：
vip ---> 数据目录挂载 --> mysqld服务
node2.upl.com IPaddr::1.1.1.188/24/eth0 Filesystem::/dev/iscsi/webroot/part1::/data mysqld
3、authkey
4、同步配置文件，启动服务
别忘记修改其余节点的心跳IP
思考：
在本实验中设定的是ping 1.1.1.1 <---- 1.1.1.1都是节点eth0(定义生成网络同时也是其中一个心跳网络)，如果心跳故障出现在eth1(第二心跳网络)，结果会怎么样？
结果：
活动节点的eth1出现故障，无法接受到心跳，也无法连接存储，但是他是无法判断存储是否连接正常（由于heartbeat使用的style-1语法风格，无法支持资源的健康判断），然后因为在eth1所在的网络无法接受到另外一个节点的心跳，所以他们会从eth0网络（另外一个心跳网络）进行ping count对比，结果对比数量一样，所以资源会切换，故障不会切换。但问题是当前的活动节点（故障节点）已经无法连接存储，所以他的mysql服务也就无法正常使用。
如何解决？
ping 1.1.1.1
ping 2.2.2.1