这是学习笔记的第 2223篇文章
读完需要
9
分钟
速读仅需7分钟
今天中午的时候，突然收到几条报警邮件，提示数据库的域名服务时断时连，感觉到不大对劲，赶紧连接到线上环境确认，发现数据库的连接池已经满了，已经登录不进去了，报错too many connections的基本信息。
这个时候就需要一个很不错的特性，那就是extra_port，在MariaDB中有，我们是用的是Percona分支，所以很快使用补充端口登录到数据库中，这是解决当前问题处理窘境的第一道坎，算是未雨绸缪，这个时候我开始联系业务方开始接入，我们同步进行问题的排查，我这里做的第一件事情就是暂时关闭数据库的高可用切换，避免高可用切换导致的不可用连环问题（这里的极端就是这个主库可能会产生数据差异，如果切到从库，问题依旧，就少了最后一道可用性屏障）。
等我连接到数据库之后，show processlist查看连接情况，发现执行SQL已经比较卡了，这里的连接池设置了650个最大连接，所以快速设置了max_connections和max_user_connections的参数值，把连接先增加一些，保证既有连接可用，能有一个缓冲，同时让业务方停止一些客户端的批量查询任务。
但是没过一会，连接池就又满了，show processlist查看，发现有不少会话是在Cleaning up的状态，所以连接数也是一升再升，最后调整到了1500左右，整个数据库开始变得很卡，查看系统负载却不高，CPU,内存和IO都消耗都不高，数据库侧没有额外的日志产生。
根据大量会话的状态为Cleaning up,并且一些前端的会话持续为Killed，我开始查看整个Buffer Pool的配置，发现这个配置有些太低了，取了一个默认的最低值，已经基本定位到这个问题之后，就需要快速恢复业务，因为目前前端的反馈是业务产生了阻塞。
MySQL 5.7版本中的新特性可以在线扩展Buffer Pool,但是在这种连接池溢出的情况下，资源消耗的争用很高，在线扩展比以往要长，所以我这边做了预案，如果数据库无法启动，立马需要切换域名到Slave侧。
重启之后很快恢复了业务，整体的连接池是比较稳定了，经过后续的排查，发现业务侧有一条SQL比较奇怪，有10张表会使用union的语法组合查询，而且都是全表扫描，经过快速评估，我们补充了索引，整个问题就基本得到了解决。
回过头来看这个问题，也是多方面导致的这个问题，把一些细节放大之后，无论是低级问题还是潜在问题，实际的问题原因都让人唏嘘不已。
我在想，如果下一次碰到这样的问题，如何能够更高效的定位问题瓶颈，快速恢复业务，应该是我们需要沉淀经验，不断提升的一个过程。
