Mycat → 高可用与负载均衡实现,满满的干货!bahttps://www.cnblogs.com/youzhibing/p/10263557.html
00 分钟
2022-8-26

前情回顾

Mycat - 实现数据库的读写分离与高可用中我们实现了mysql的读写分离与高可用,有几个点我们回顾下
1、数据的同步在mysql层面实现的,mycat不负责任何的数据同步,我们需要配置mysql的主从复制来实现数据的同步;
2、数据库的读写分离是mycat最常用的场景之一,我们的应用代码只需要关注业务代码,而不需要处理数据库读写、分片问题,这些都由Mycat实现,简化了开发;
3、读写分离往往伴随着高可用,而Mycat同时支持这两者;
那是不是就完美无缺了呢? 显然还有点小瑕疵,此时我们的Mycat是单点部署的,如果Mycat服务挂了,那么整个数据库端就挂了,整个应用也就不能正常服务了,那怎么办了? 很明显,我们需要实现Mycat的高可用,具体实现我们往下看。

keepalived实现Mycat高可用

centos7_1 (192.168.1.110)上搭建mycat

上篇博文中,我们搭建的读写分离各组件关系如下
notion image
此时还是单节点的mycat,我们还需要搭建一个mycat,搭建过程可以参考192.168.1.212上mycat的搭建,具体我就不演示了,搭建好之后各组件关系如下
notion image
昨天我们测试了master mysql宕机的情况,后续的DML SQL与Select SQL都是走的slave mysql,所以此时mysql的主从复制已经被破环、mycat的writeHost也切换到了192.168.1.211,我们需要重新配置mysql的主从复制,192.168.1.210仍是主,192.168.1.211回退为slave,并将192.168.1.212上mycat的writeHost进行还原(只需要将mycat/conf/dnindex.properties文件删了即可);生产环境不要这么处理,按上篇说的处理。
我们来看下测试结果
notion image
可以看到,192.168.1.110上的mycat与192.168.1.212上的mycat具有完全一样的功能,但此时两者还没有任何联系,彼此也互不影响。我们可以在应用代码中集成两个mycat,由代码控制mycat的高可用,这种方式可行但不可取,代码应该更多的关注业务层,而不是处理数据库层面的高可用问题。mycat的高可用应该就由更专业的组件来处理。

keepalived实现vip对外提供服务

VIP:192.168.1.200、master:192.168.1.212、backup:192.168.1.110
keepalived的搭建过程可参考:主从热备+负载均衡(LVS + keepalived),这里就不做详细的演示了。
192.168.1.212(master)上keepalived.conf
192.168.1.110(backup)上keepalived.conf
mycat存活检测脚本check_pid.sh
脚本目录:/usr/local/src/mycat/,给脚本可执行权限:[root@centos7-01 src]# chmod -R 755 mycat/check_pid.sh
各组件关系图如下
notion image
如上图所示,外部应用向192.168.1.200发送sql请求,keepalived完成VIP到ip的映射,请求会落到具体的某个mycat上,再由mycat转发到具体的mysql上。同一时刻只会有一个keepavlied处理VIP,一般而言是优先级高的keepalived会成为master,负责VIP的映射。各组件配置好之后,我们来看看测试结果

1、vip的正常绑定与切换

notion image
一开始212和110都没有启动mycat,优先级分别是100,90,所以vip在212上,212成为master,110成为backup;接着我们启动了110上的mycat,检测脚本返回0,vrrp_script中script为true,此时110的权重=90+20,大于212的100,110抢占vip成为master,而212则降级成为backup;然后我们启动了212上的mycat,212的权重=100+20,大于110的110,vip漂浮到212上,212成为master,110成为backup;最后我们停了212上的mycat,权重=100,vip又漂到了110上。如果我们接着停了110上的mycat,则vip又会漂到212上。
权重 = priority + weight * script的结果(脚本执行返回0,script则为true,否则script为false),权重大的抢占到vip,成为master;杀掉keepalived进程,vip也会进行正确的转移,具体我就不展示测试结果,大家可以自行去测试。

2、mycat高可用

notion image
我们通过vip可以进行正常的sql请求,当212上的mycat停了,vip漂到了110上,通过vip仍然可以进行sql请求,应用端根本感知不到后端vip的漂移、mycat的切换,实现了mycat的高可用。
这种方案已经可以满足大多数的应用场景了,master上的mycat对外服务,backup上的mycat仅作为备用以防master宕机,backup上的mycat基本上不提供服务,就是起到一个以防万一的作用,并发量不高的应用采用此种方案就可以了。如果并发量高了,master上的mycat压力太大,那我们就需要考虑将backup上的mycat也利用起来了,并做一个负载均衡,减轻master上的mycat压力,并充分利用backup上的mycat,具体实现请往下看。

lvs实现Mycat的负载均衡

Mycat的高可用是实现了,但美中不足的是没有物尽其用,我们不难发现,Mycat的两个节点其实只有一个对外服务,另一个完全备用(以备基本不会发生的宕机),宕机的概率本来就小,备用机基本相当于没用了,那可不可以将备用机利用起来了? 我们可以将主备Mycat都利用起来,并进行负载均衡,减小主Mycat的压力,如果其中一个节点宕机了,则由另一个节点完全接管,继续正常提供服务。
notion image
组件结构图如上所示,keepalived负责lvs的健康检测与高可用,lvs负责mycat的负载均衡与心跳检测。如果服务器不够,keepalived、lvs和mycat可以部署在一起,但不推荐,组件都部署在同一个服务器上,风险太大,分散部署,可以降低风险。keepalived + lvs的具体部署过程可参考主从热备+负载均衡(LVS + keepalived),具体配置文件如下
192.168.1.214(master)上keepalived.conf
192.168.1.213(backup)上keepalived.conf
192.168.212、192.168.1.110上的realserver.sh内容一致
在/usr/local/src/目录下,给脚本可执行权限:[root@centos212 ~]# chmod -R 755 /usr/local/src/realserver.sh
按照上述结构图,从右往左逐个启动组件:先启动mysql,接着启动mycat,然后启动realserver.sh,再启动keepalived。我们来看下负载均衡效果
notion image
负载均衡效果我们可以通过ipvsadm -l命令来查看,具体体现在ActiveConn和InActConn值,ActiveConn是活动连接数,也就是tcp连接状态的ESTABLISHED,而InActConn是指除了ESTABLISHED以外的,所有的其它状态的tcp连接。因为./mysql -h192.168.1.200 -P8066 -uroot -p123456 -DTESTDB  -e 'select @@hostname'是瞬时的,这个连接就归为InActConn,如果我们想测试ActiveConn,我们可以用./mysql -h192.168.1.200 -P8066 -uroot -p123456 -DTESTDB,其实与我们平时操作mysql是一样的。从上图中可以看出,是达到了负载均衡效果的,192.168.1.110:8066与192.168.1.212:8066轮着来处理。
可能会有人对上图中./mysql -h192.168.1.200 -P8066 -uroot -p123456 -DTESTDB  -e 'select @@hostname'的返回值有疑问:为什么总是centos211? 这个sql其实就是查询mysql的主机名,注意是mysql服务器的主机名,不是mycat的主机名!sql最终的执行者是mysql! 而我们知道mycat对mysql做了读写分离,也就是说./mysql -h192.168.1.200 -P8066 -uroot -p123456 -DTESTDB  -e 'select @@hostname'始终会在mysql slave上执行,而我们的mysql slave的ip是192.168.1.211,其hostname是centos211,所以看到的hostname总是centos211。

总结

1、很多时候我们都只需要实现mycat的高可用,而不需要实现mycat的负载均衡;组件越多,越容易出错,也更难以维护;没有一成不变的最优方案,只有在合适时机的最佳方案;
2、keepalived的作用,有没有lvs,keepalived启动的作用是有所区别的。没有lvs时,keepalived负责vip的映射与转移、mycat的存活检测;有lvs时,Keepalived负责vip的映射与转移、RealServer的健康状态检查。不管有没有lvs,keepalived都会负责VIP的映射与转移,实现master和slave主机之间failover,达到高可用目的;
3、各个组件的职责都很明显,mysql负责sql的执行,mycat负责mysql的读写分离与高可用,lvs负责mycat的负载均衡与高可用,keepalived负责vip相关工作以及lvs的高可用。各个组件的角色弄清楚了,搭建起来也就不难了;
4、《Mycat权威指南》中采用haproxy + keepalived实现mycat的高可用和负载均衡,我就不再重复讲了,有兴趣的可以去实践一把;另外留个疑问:nginx可不可实现mycat的负载均衡?
5、关于搭建过程中遇到的问题,包括keepalived的“脑裂”问题,以及一些其他大家在搭建过程中可能会遇到的问题,可查看:keepalived实现mycat高可用问题排查;道路坎坷,布满荆棘,定让你大吃一惊!

评论