企业中MySQL高可用集群架构三部曲之MM+keepalived


各位老铁们,老张与大家又见面了。看到各位在博客里面给我的留言和访问量的情况,我很是欣慰,也谢谢大家对我的认可。我写这些博客,就是想把自己对于MySQL数据库的一些看法和自己平时的实战经验分享出来,我们可以一起探讨,共同进步。也保证今后只要一有空就更新博文,推出更多的干货。
我的学生经常对我说:“张老师,每次我遇到报错,有时还是会百度,但是最烦的是不知道百度哪篇帖子说的是正确的”.其实这些呢,都是因为自己还没有对MySQL数据库核心知识的不熟悉,和对技术掌握的不牢固。平时下得功夫还是不到位。我们做技术这个行业,还是需要自己给自己加发条,促使自己每天都要学习一些新的知识。理论配合实验一起,先要学会多问自己几个问题,一个实验多做几遍,可能会得到不同的实验效果。学习知识要踏实下来,学会多做实验总结。我想今后再遇到报错,可能自己就会有一个清晰的解题思路,这个需要一定时间的磨练。
也有人经常问Oracle和MySQL到底有啥区别,其实MySQL数据库上手很简单,难的是后期架构的设计与维护。老张三部曲中第一部曲MHA希望对开发云主机域名大家在线上部署方面有帮助。
今儿给大家介绍第二部曲,MM+keepalived的环境部署,我们会多种数据库的架构就可以灵活应用到我们的公司。根据公司业务的不同,选择合适的集群架构。
独家新课程上线>>MySQL体系结构深入剖析及实战DBA视频课程

MM+keepalived
简介双主配合keepalived这种架构设计,也是基于主从复制的原理而搭建的。使用MySQL主主复制技术+Keepalived是一种简单、便捷的解决方案,在高可用集群环境中,keepalived使用VIP,使用Keepalived自带的服务监控功能和自定义脚本来实现MySQL故障时自动切换,非常灵活。
应用范围:
一般中小型公司都使用这种架构,搭建比较方便简单;可以采用主从或者主主模式,在 master 节点发生故障后,利用 keepalived 高可用机制实现快速切换到 slave 节点。原来的从库变成新的主库。
个人建议:一定要完善好切换脚本,keepalived 的切换机制要合理,避免切换不成功的现象发生。
从库的配置尽快要与主库一致,不能太次;避免主库宕机发生切换,新的主库(原来的从库)影响线上业务进行。
对于延迟的问题,在这套架构中,也不能避免。可以使用 mysql 5.7 中增强半同步完成。也可以改变架构使用 PXC,完成时时同步功能,基本上没有延迟;
keepalived 无法解决脑裂的问题,因此在进行服务异常判断时,可以修改我们的判断脚本,通过对第三方节点补充检测来决定是否进行切换,可降低脑裂问题产生的风险。
采用 keepalived 这个架构,在设置两节点状态时,都要设置成不抢占模式,都是 backup 状态,通过优先级,来决定谁是主库。避免脑裂,冲突现象发生。
安装好 mysql 需要的一些依赖包;建议配置好 yum 源,用 yum 安装 keepalived 即可。
搭建架构之前理清思路:
首先需要装有两台mysql的数据库服务器,两者之间互为主从模式,都可读写。其实就只有一台服务器A负责数据的写入工作,而另一台服务器B作为我们的备用数据库;安装keepalived的软件包,个人建议使用yum安装就可以,很方便。当然我们要知道yum安装之后的软件路径在什么位置。整理好keepalived的配置文件,理清keepalived的三种状态信息。还要准备一个监控MySQL的脚本,便于检测到宕机顺利发生切换的过程。所有提供服务的从服务器与备用服务器B进行主从同步。—-双主从库模式在两台服务器A和B,当配置keepalived的参数文件中,要注意两台机器都要采用backup这种状态,就是nopreempt这种非抢占模式,避免出现冲突,发生脑裂现象。
架构图展示:实验部署环境介绍:192.168.56.100 主 —master1
192.168.56.101 备库—master2都是干净环境没有任何数据VIP:192.168.56.111
MySQL数据库版本5.7.14,采用GTID模式搭建主从环境
注意事项:两台机器的防火墙必须是关闭状态。两台MySQL数据库配置文件中server-id绝对不能一样,要不会报1593这个主从同步的错误,导致搭建不成功。

实战开始:首先先要搭建两台MySQL数据库为互为主从的架构模式。添加主从同步账号:在192.168.56.100:grant replication slave on *.* to ‘bak’@’192.168.56.%’ identified by ‘123456’;flush privileges;

在192.168.56.101:grant replication slave on *.* to ‘bak’@’192.168.56.%’ identified by ‘123456’;flush privileges;
配置同步信息:先在192.168.56.101上:CHANGE MASTER TO MASTER_HOST=’192.168.56.100′,MASTER_USER=’bak’,MASTER_PASSWORD=’123456′,master_auto_position=1;打开主从同步开关:start slave;查看主从同步状态:
再在192.168.56.100上:配置主从同步信息
CHANGE MASTER TO MASTER_HOST=’192.168.56.101′,MASTER_USER=’bak’,MASTER_PASSWORD=’123456′,master_auto_position=1;开启主从开关:start slave;查看主从同步状态
分别两台机器上安装keepalived的软件包,可以使用yum安装方式yum -y install keepalived;证明keepalived软件已经存在:

在两台机器上分别配置检测MySQL数据库的脚本:首先进入到yum安装后的软件目录下:脚本通过查看MySQL进程的存在,和是否可以连接,来判断MySQL的状态(这里只展现了脚本中判断的一部分)

在两台机器上修改keepalived的配置文件:192.168.56.100上面
192.168.56.101上面:总结:可以看到两台机器的state都是backup并且都是非抢占模式nopreempt,通过优先级的高低来决定谁是主库。(这里192.168.56.100是主)还有注意virtual_router_id(虚拟路由id)要保持一致。
接下来可以启动两台机器的keepalived进程:192.168.56.100:
观察日志中信息的变化:cat /var/log/messages可以看到它从backup状态切换到master的状态了,并且发送了一个广播协议,证明192.168.56.111已经在本台机器上面,其他机器不要再使用了。192.168.56.101:cat /var/log/messages这台服务器就是正常的backup状态,时刻准备着接管主库的服务。

模拟一下主库宕机的故障切换:主库192.168.56.100上面执行关闭MySQL服务操作:这时再查看一下keepalived日志的情况已经把vip removed了,并且keepalived的状态变成了fault
在备库192.168.56.101上面查看日志:备库已经从backup状态切换成master状态了。并且VIP(192.168.56.111)已经切换过来。查看ip地址:主备库切换成功。
实战演练过程结束,希望对大家学习MySQL高可用集群有帮助。
今后我们可能还会遇到其他的MySQL高可用架构,学习它的时候,先不要忙于搭建,要先弄清原理,整理好实验过程的思路,遇到报错,一步步地去排查。自己的水平也会在这个历练的过程中,得到提升。
今后我们可以一起讨论,在写博的过程中难免可能会有一些笔误,或是想不周全的地方,希望大家谅解。有不对的地方欢迎各位老铁指定。(MySQL高可用集群第二部曲完结
第一步曲直通车>> 企业中MySQL主流高可用架构实战三部曲之MHA

相关推荐: 故障排除指南:MySQL运行内存不足怎么办?

故障排除对于所有人来说都不会是一件有趣的事情,尤其是在没有崩溃报告的情况下。如果MySQL因内存不足而崩溃时应该怎么办?Peter Zaitsev曾在2012年写过的一篇博客中给出了许多有用的提示,而利用新版本的MySQL(5.7及以上)和performanc…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 06/09 15:28
下一篇 06/09 15:28

相关推荐