MySQL的高可用解决方案其实有很多种(想了解自行百度),这里只说其中一种:MHA。这也是当前比较主流的方案。
在搭建MHA之前应该先保证已经安装配置好了MySQL的主从/集群。因为既然是高可用架构,那么针对的肯定是多台设备,单机的话谈不上高可用。
MySQL的主从搭建过程这里就不说了,可以看这里: MySQL搭建主从架构
本次搭建环境:centos7.8 + mysql5.7.31
现在的架构是 :
101:主节点
102:从节点1
103:从节点2
手动将101的MySQL主节点关闭,在102的节点上查看VIP,发现配置的VIP:192.168.232.105已经从101节点漂移到102节点了。
然后在103的节点上可以看到主节点确实已经变成了 102
到此,MHA 搭建大功告成啦!
MHA 的切换过程,共包括以下的步骤:
最后说明一点,宕机的节点,重启后由于MySQL机制问题不会自动加入到集群中,需要我们手动加入。
某天晚上,数据库 hang 住,现象是:
无奈之下通过强制 kill 掉进程,重启数据库恢复。
这里暂且不说 hang 住的原因,仅分析数据库 hang 住,但是 MHA 未触发切换。
先说下结论,MHA 默认使用长连接对数据库做 ping 健康 检测(执行 select 1 as Value ),4次无法连接 MySQL 则触发切换。 前面数据库 hang 住只是新的连接无法建立,但是老连接却没有影响,且 MHA 的 健康 检测语句很简单,只在 server 层进行了检测,不涉及到 InnoDB 层,所以 MHA 认为 MySQL 是 健康 的,并没有作出任何决策。
MHA 从 0.53 版本开始支持 ping_type 参数设置如何检查 master 的可用性。支持3个 value :
通过将 ping_type 修改设置为 connect ,MHA 每次进程状态检测,需要新建连接,新链接无法成功建立,就触发了切换。
三种检测机制代码:
MHA 配置文件
模拟服务器CPU满负载,数据库无法建立新连接 编写一个简单的c程序,如下:
编译:
执行:
另外再跑两个 mysqlslap 压测程序:
有兴趣的同学可自行测试一下
调用链路:
MHA 监控进程启动后,会持续监控主节点的状态,主要的 健康 检测函数是 wait_until_unreachable()。
在这个函数中会有一个死循环,持续地进行 健康 检测
1.首先,测试连接,连接正确返回0,否则返回1。
2.测试连接成功后,则进行 健康 状态检测(前面说的3种方式);如果连续4次连接失败,则在第4次的时候会使用第二脚本进行检测(如果定义了的话),如果检测通过,则认为 master 挂掉
关键函数 wait_until_unreachable()代码:
①在文件【my.ini】的【mysqlId】字段最下面加入【skip-grant-tables】,重启mysql服务②再进入mysql控制台按照上面第二种改密码的方式重新修改密码。
③改完密码后将【my.ini】中添加的【skip-grant-tables】删掉。
④重新启动服务
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)