最近使用Percona MySQL 5.7版本遇到的坑

监控DB由于使用的TokuDB引擎,因此选择使用Percona MySQL 5.7版本,在使用过程中遇到了比较多的坑,在这里做一下简单的记录,希望对广大DBA有帮助。

load文件飙升导致的DB雪崩

在上层机器(mqproxy)出问题的时候,会导致load文件飙升,导致监控DB大量的load线程堆积,造成监控DB雪崩,比如2月15号的一次异常:

最近使用Percona MySQL 5.7版本遇到的坑_第1张图片

DB雪崩的时候有大量的load线程堆积,并且机器的写入性能之前下降,直到超过最大连接数,业务无法访问。

这种场景的解决办法有两个:

1、业务上层进行控制,对DB进行保护,控制load的线程数或者文件数

2、DB启用线程池,控制DB并发load的线程数

目前DB已经完成2的改造,1的改造也正在进行中。

使用线程池内存问题

出于对DB做保护,我们准备在监控DB启用线程池功能。为了安全起见,先在从机启用,并进行持续观察,在观察的过程中发现在启用了线程池以后,内存飙升了8G左右,如下图:

最近使用Percona MySQL 5.7版本遇到的坑_第2张图片

不但启用线程池后内存飙升了8G左右,而且内存还在持续增长,很明显启用线程池后存在内存泄漏了。

这个问题在网上也有不少的人遇到,确认是percona的bug导致(https://jira.percona.com/browse/PS-3734),只有开启Performance_Schema和ThreadPool的时候才会出现,解决办法是关闭Performance_Schema即可,具体操作方法是在配置文件添

加performance_schema=off

然后重启MySQL就OK。下面是关闭PS后的内存使用情况对比:

最近使用Percona MySQL 5.7版本遇到的坑_第3张图片

线程池启用后的高可用探测问题

在描述问题之前,先来描述一下线程池是如何分配连接和控制的:

线程池会根据参数thread_pool_size的大小分成若干的group,每个group各自维护客户端发起的连接,当客户端发起连接到MySQL的时候,MySQL会跟进连接的线程id(thread_id)对thread_pool_size进行去模,从而落到对应的group。thread_pool_oversubscribe参数控制每个group的最大并发线程数,每个group的最大并发线程数为thread_pool_oversubscribe+1个,若对应的group达到了最大的并发线程数,则对应的连接就需要等待。

在线上配置了几组机器使用线程池后,发现有1组机器发生自动切换,排查了机器的负载、MySQL错误日志、操作系统日志、高可用日志以后,确定是由于启用线程池问题导致,具体的原因描述如下:

启用线程池以后,相当于限制了MySQL的并发线程数,当达到最大线程数的时候,其他的线程需要等待,新连接也会卡在连接验证那一步,这时候会造成拨测程序连接MySQL超时,拨测程序连接实例超时后,就会认为master已经出现问题,从而启动自动切换的操作,将业务切换到从机。

这种情况有两种解决办法:

1、启用MySQL的旁路管理端口,监控和高可用相关直接使用MySQL的旁路管理端口

    具体做法为是在my.cnf中添加如下配置后重启,就可以通过旁路端口登录MySQL了,不受线程池最大线程数的影响:

    extra_max_connections = 8

    extra_port = 33333

    备注:建议启用线程池后,这个也添加上,方便紧急情况下进行故障处理。

2、修改高可用探测脚本,将达到线程池最大活动线程数返回的错误做异常处理,类似于当作超过最大连接数的场景(备注:超过最大连接数只告警,不进行自动切换)

监控这边选择了解决方法2,因为这种方式改动量最小。


简单总结

以上就是最近使用Percona MySQL时候遇到的几个问题,通过这几个问题概括出几个需要广大DBA们注意的事情:

1、上层应该对DB进行保护,防止DB出现雪崩

2、在上新功能的时候,一定记得灰度、灰度、灰度

3、灰度的时候,注意密切观察线上DB的性能指标(内存、性能、IO以及其他和变更相关的指标)

4、综合考虑各种解决方案,选择最适合的方案

你可能感兴趣的:(最近使用Percona MySQL 5.7版本遇到的坑)