故障原因
上午10:14左右出现大量慢sql导致mysql服务器的cpu飙升到100%
处理过程
阿里云查看性能趋势,发现在10:13:28cpu飙升到100%
排查思路:
8月1号阿里云临时把我们的IOPS调到了7000,一周后调回原值5000,
排查10:13:28附近的IOPS,为3581.5,并未达到峰值7000
查看扫描行数并未发现明显飙升
查看10:14:00之前5分钟内的sql洞察,在10:13:28秒左右并没有发现明显异常
在10:11:56出现一次比较明显的飙升,定位到以下查询语句
该sql在当时的执行时间大概在3秒左右,理论上不应该是这句sql引起的cpu飙升
继续排查慢日志明细,发现以下几句sql执行时间在12、3秒左右,执行开始时间和飙升发生时间比较接近,把这几句sql单独拿出来放在只读实例中执行都是一秒之内返回,目前来看不可能是单独的几条sql引起的cpu飙升,联系阿里云进行排查,那边给出的回复是并发量达到一定程度,导致主实例的buffer pool占满,拿不到free pages
优化思路为通过阿里云的数据库代理,自动对请求进行转发,写请求转发到主实例上,读请求转发到只读实例上,减少主实例上的大量读请求压力,目前对uat数据库设置了代理,将xxx-pro的uat环境连接地址改成了数据库代理地址,先在uat环境测试一下主流程是否可以正常执行,确保可以正常执行的情况下再对生产环境进行调整
暴露的问题
目前存在较多慢sql,部分慢sql单从sql层面优化空间不大
改进措施
目前发现访问量较大的慢sql主要集中在往来单位查询、台账查询和导出查询等业务相关的sql,已对uat环境的xxx-pro设置了数据库代理,计划在今天发版后对往来单位查询对应的xxx-data-service也使用数据库代理,需要验证下主流程是否可以正常执行
