注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

MySQL基于MHA+VIP部署篇

MySQL 彭东稳 6815次浏览 已收录 0个评论

本章节基于:MySQL基于MHA高可用部署篇(二)

通过上一个章节实验,我们知道mha可以正常切换主从,但是当mysql正常切换之后,应用中是无法正常自动切换的,这时就需要vip了。VIP配置可以采用两种方式,一种通过keepalived的方式管理虚拟ip的浮动;另外一种通过脚本方式启动虚拟ip的方式(即不需要keepalived或者heartbeat类似的软件)。

第一种:通过keepalived配置VIP

keepalived方式管理虚拟ip,keepalived配置方法如下:

1)下载软件进行并进行安装(两台master,准确的说一台是master,另外一台是备选master,在没有切换以前是slave)

2)配置keepalived的配置文件,在master上配置(10.99.73.9)

其中router_id MySQL HA表示设定keepalived组的名称,将192.168.0.88这个虚拟ip绑定到该主机的eth1网卡上,并且设置了状态为backup模式,将keepalived的模式设置为非抢占模式(nopreempt),priority 150表示设置的优先级为150。下面的配置略有不同,但是都是一个意思。

在候选master上配置(10.99.73.10)

3)启动keepalived服务,在master上启动并查看日志.

发现已经将虚拟ip 10.99.73.100绑定了网卡eth0上。

在另外一台服务器,候选master上启动keepalived服务,并观察

从上面的信息可以看到keepalived已经配置成功。

现在我们关掉master keepalived,来测试主从切换。

可以看到正常切换过来了,下面要做的就是使用keepalived检查mysql是否存活。

注意:上面两台服务器的keepalived都设置为了BACKUP模式,在keepalived中2种模式,分别是master->backup模式和backup->backup模式。这两种模式有很大区别。在master->backup模式下,一旦主库宕机,虚拟ip会自动漂移到从库,当主库修复后,keepalived启动后,还会把虚拟ip抢占过来,即使设置了非抢占模式(nopreempt)抢占ip的动作也会发生。在backup->backup模式下,当主库宕机后虚拟ip会自动漂移到从库上,当原主库恢复和keepalived服务启动后,并不会抢占新主的虚拟ip,即使是优先级高于从库的优先级别,也不会发生抢占。为了减少ip漂移次数,通常是把修复好的主库当做新的备库。

4)MHA引入keepalived(MySQL服务进程挂掉时通过MHA停止keepalived)

要想把keepalived服务引入MHA,我们只需要修改切换是触发的脚本文件master_ip_failover即可,在该脚本中添加在master发生宕机时对keepalived的处理。

编辑脚本/usr/local/bin/master_ip_failover,修改后如下,我对perl不熟悉,所以我这里完整贴出该脚本。

在MHA Manager修改脚本,修改后的内容如下(参考资料比较少):

/usr/local/bin/master_ip_failover添加或者修改的内容意思是当主库数据库发生故障时,会触发MHA切换,MHA Manager会停掉主库上的keepalived服务,触发虚拟ip漂移到备选从库,从而完成切换。当然可以在keepalived里面引入脚本,这个脚本监控mysql是否正常运行,如果不正常,则调用该脚本杀掉keepalived进程。

MHA manager配置文件调用方式如下,自动故障切换和在线切换都是使用这个脚本即可。

比如有如下环境都已配置好,如下:

mysql01为mysql master+keepalived master+vip(10.99.73.100)

mysql02为mysql slave+keepalived slave+vip(10.99.73.100)

mysql03为mysql slave

mha为monitor监控整个复制组,然后你可以停掉mysql01的mysql master实例,通过mha监控加master_ip_failover脚本达到vip转移到mysql02主机,同时mysql02成为新的mysql master,而mysql03成为mysql02的从。

下面就是整个mha切换的日志:

结果表明vip+mysql master都已经正常切换到了mysql02主机,具体内容细看,这里就不做详细说明了。在使用keepalived时,就不需要arping工具了,高版本keepalived自带了arp处理。

第二种:通过脚本的方式管理VIP

这里是修改/usr/local/bin/master_ip_failover,也可以使用其他的语言完成,比如Python语言。使用Python脚本编写的failover这里就不介绍了。修改完成后内容如下,而且如果使用脚本管理vip的话,需要手动在master服务器上绑定一个vip。

通过脚本来维护vip的测试我这里就不说明了,自行测试,脚本如下(测试通过)。

使用方式如下,自动切换和在线切换都是使用这个脚本即可。

为了防止脑裂发生,推荐生产环境采用脚本的方式来管理虚拟ip,而不是使用keepalived来完成。但是当我们有了VIP之后,在切换时还有一个问题,我们知道网络模型OSI中二层数据链路是靠MAC地址通信的,所以上层无论三层或二层交换机是缓存有VIP的ARP(MAC和IP对应关系)表,交换机靠这个表来进行数据包的转换转发。所以当我们VIP切换后,上层交换机并不会立马刷新自己的ARP缓存表,这就需要我们人工干预了。

其实就是在我们进行切换时,可以通过使用一个arping命令实现。arping是在局域网中使用ARP请求判断目标主机是否在线的工具。你可以使用IP地址或MAC地址作为它的测试目标(因为APRING程序工作于OSI模型中的第二层,ARP协议的数据包无法通过路由器和网关,所以它只能用来检测局域网中的主机)。其命令语法如下:

-b:用于发送以太网广播帧(FFFFFFFFFFFF)。arping一开始使用广播地址,在收到响应后就使用unicast地址。

-q:quiet output不显示任何信息。

-f:表示在收到第一个响应报文后就退出。

-w timeout:设定一个超时时间,单位是秒。如果到了指定时间,arping还没到完全收到响应则退出。

-c count:表示发送指定数量的ARP请求数据包后就停止。如果指定了deadline选项,则arping会等待相同数量的arp响应包,直到超时为止。

-s source:设定arping发送的arp数据包中的SPA字段的值。如果为空,则按下面处理,如果是DAD模式(冲突地址探测),则设置为0.0.0.0,如果是Unsolicited ARP模式(Gratutious ARP)则设置为目标地址,否则从路由表得出。

-I interface:设置ping使用的网络接口。

到此为止,基本MHA集群已经配置完毕。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (2)or分享 (0)
关于作者:

您必须 登录 才能发表评论!