15、 Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节

yanchuen

　　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）架构拓扑 　　架构说明： 　　一主多从最常用的架构，多个从库可以使用lvs来提供读的负载均衡。 　　解决一主单点的问题，当主库宕机后，可以实现主库宕机后备节点自动接管，所有的从库会自动和新的主库进行同步，实现了mysql主库的热备方案 　　（2）系统环境： 　　（3）部署环境 　　（4）主库服务器数据分区信息
2、heatbeat安装部署	(1)、配置服务器间心跳连接路由 　　主节点 　　[root@master1 ~]# route add -host 172.16.4.3 dev eth2 create database coral2; 　　Query OK, 1 row affected (0.08 sec)                      #说明：VIP地址已经漂移到master2上面 　　[root@slave1 ~]# mysql -uroot -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running" 　　Slave_IO_Running: Yes 　　Slave_SQL_Running: Yes 　　[root@slave1 ~]# mysql -uroot -e "show databases like 'coral%'" 　　+-------------------+ 　　| Database (coral%) | 　　+-------------------+ 　　| coral1 | 　　| coral2 | 　　+-------------------+ 　　#注意：高可用主备节点切换过程中，会有一段时间从库才能连接上，大于在60秒内 　　#说明：此时主从同步是正常的 　　3)、模拟高可用主节点宕机恢复 　　[root@master1 ~]# /etc/init.d/heartbeat start 　　[root@master1 ~]# mysql -uroot 　　mysql> create database coral3; 　　[root@slave1 ~]# mysql -uroot -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running" 　　Slave_IO_Running: Yes 　　Slave_SQL_Running: Yes 　　[root@slave1 ~]# 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中设计了智能锁，正在提供服务的一方只在发现心跳全部断开时才会启用磁盘锁，平时就不上锁