15、 Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节
15、 Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节参考自：http://oldboy.blog.运维网.com/2561410/1240412
heartbeat和keepalived应用场景及区别
很多网友说为什么不使用keepalived而使用长期不更新的heartbeat，下面说一下它们之间的应用场景及区别：
1、对于web，db，负载均衡(lvs,haproxy,nginx)等，heartbeat和keepalived都可以实现
2、lvs最好和keepalived结合，因为keepalived最初就是为lvs产生的，(heartbeat没有对RS的健康检查功能，heartbeat可以通过ldircetord来进行健康检查的功能)
3、mysql双主多从，NFS/MFS存储，他们的特点是需要数据同步，这样的业务最好使用heartbeat，因为heartbeat有自带的drbd脚本
总结：
无数据同步的应用程序高可用可选择keepalived，
有数据同步的应用程序高可用可选择heartbeat（DRBD） 。
1、
安装部署准备
（1）架构拓扑
http://blog.运维网.com/e/u261/themes/default/images/spacer.gif
架构说明：
一主多从最常用的架构，多个从库可以使用lvs来提供读的负载均衡。
解决一主单点的问题，当主库宕机后，可以实现主库宕机后备节点自动接管，所有的从库会自动和新的主库进行同步，实现了mysql主库的热备方案
（2）系统环境：
http://blog.运维网.com/e/u261/themes/default/images/spacer.gif
（3）部署环境
http://blog.运维网.com/e/u261/themes/default/images/spacer.gif
（4）主库服务器数据分区信息
http://blog.运维网.com/e/u261/themes/default/images/spacer.gif
2、heatbeat安装部署
(1)、配置服务器间心跳连接路由
主节点
# route add -host 172.16.4.3 dev eth2 create database coral2;
Query OK, 1 row affected (0.08 sec) #说明：VIP地址已经漂移到master2上面
# mysql -uroot -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
# mysql -uroot -e "show databases like 'coral%'"
+-------------------+
| Database (coral%) |
+-------------------+
| coral1 |
| coral2 |
+-------------------+
#注意：高可用主备节点切换过程中，会有一段时间从库才能连接上，大于在60秒内
#说明：此时主从同步是正常的
3)、模拟高可用主节点宕机恢复
# /etc/init.d/heartbeat start
# mysql -uroot
mysql> create database coral3;
# mysql -uroot -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
# mysql -uroot -e "show databases like 'coral%'"
+-------------------+
| Database (coral%) |
+-------------------+
| coral1 |
| coral2 |
| coral3 |
+-------------------+
#说明：高可用主节点故障恢复后也不影响主从库的同步
7、高可用脑裂问题及解决方案
(1)、导致裂脑发生的原因
1、高可用服务器之间心跳链路故障，导致无法相互检查心跳
2、高可用服务器上开启了防火墙，阻挡了心跳检测
3、高可用服务器上网卡地址等信息配置不正常，导致发送心跳失败
4、其他服务配置不当等原因，如心跳方式不同，心跳广播冲突，软件BUG等
(2)、防止裂脑一些方案
1、加冗余线路
2、检测到裂脑时，强行关闭心跳检测(远程关闭主节点，控制电源的电路fence)
3、做好脑裂的监控报警
4、报警后，备节点在接管时设置比较长的时间去接管，给运维人员足够的时间去处理(人为处理)
5、启动磁盘锁，正在服务的一方锁住磁盘，裂脑发生时，让对方完全抢不走"共享磁盘资源"
磁盘锁存在的问题：
使用锁磁盘会有死锁的问题，如果占用共享磁盘的一方不主动"解锁"另一方就永远得不到共享磁盘，假如服务器节点突然死机或崩溃，就不可能执行解锁命令，备节点也就无法接管资源和服务了，有人在HA中设计了智能锁，正在提供服务的一方只在发现心跳全部断开时才会启用磁盘锁，平时就不上锁
页:
[1]