MySQL 运维实战课
张新铭(俊达)
云掣科技资深数据库专家,前淘宝网、支付宝数据库专家
763 人已学习
新⼈⾸单¥59
MySQL 运维实战课
15
15
1.0x
00:00/00:00
登录|注册

15|非典型数据库故障解析:数据库故障一定是数据库的锅吗?

你好,我是俊达。
在前两讲中,我分别介绍了 MySQL 和 Linux 操作系统问题排查的基本思路,提供了一些判断数据库和操作系统是否有问题的方法。这一讲我们就以一个生产环境中发生的故障为例,来看看怎么运用前面讲到的基本方法,来分析和定位真实环境下的问题。

背景介绍

这是我们公司服务的一家客户在线业务系统中发生的故障。这家客户提供在线支付业务,大量的消费者日常都会使用到这项服务。比如我们中午或傍晚到店里扫码点餐付款时,或者在商场里扫码付款时,都可能会用到这项服务。当时,我们给这家公司提供了数据库运维保障的服务。客户的核心业务数据库采用了国内头部的一家云厂商提供的 RDS for MySQL 产品。
有一天下午,快接近 6 点钟的时候,短促的告警声打破了办公室的平静,客户的告警通知群里面,出现了大量的实例 CPU 和活跃会话数的告警消息。通过监控大屏,我们发现问题都出在一个核心数据库上,数据库实例的 CPU 资源,几乎在瞬间达到了 100%。同时客户也反馈,业务端有大量的付款失败了。

怎么分析数据库 CPU 使用率高的问题?

对于数据库 CPU 使用率打满的问题,一般我们都会先从实例中运行的 SQL 入手。有两种情况都可能会导致 CPU 打满,一种情况是实例中运行了执行效率特别低的 SQL,如大表全表扫描、大表连接并且缺少合适的连接条件或连接索引。另外一种情况是 SQL 的执行频率太高了。更差的情况是,SQL 效率很低,同时执行的并发量还很高。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
  • 解释
  • 总结

1. 数据库CPU使用率突然上升到100%,导致业务出现大量付款失败的问题。 2. 通过全量SQL分析,找到了一些SQL并进行了优化,但并非引起故障的真正原因。 3. 故障再次发生后,通过监控指标确认数据库CPU在极短时间内冲到100%,并且数据库连接数也上涨了好几倍,推测是应用程序瞬间创建了大量连接并执行SQL,超过了MySQL的承受能力。 4. 通过RDS的监控指标确认数据库的CPU、SQL执行量和连接数的变化趋势,以及观察到指标暴涨之前的短暂下跌过程,来推测故障的根本原因。 5. Redis中执行 keys * 命令是非常危险的一个操作,可能导致其他请求被阻塞,最终引起MySQL故障。 6. 在分析问题时,要从系统全局出发,不能局限在数据库内部,同时要注意给问题下结论时,要多问问自己,这个问题真的是这个原因引起的吗? 7. 思考如何区分在数据库繁忙时执行效率变差的SQL中的罪魁祸首和受害者,找到真正需要优化的SQL。 8. 快速恢复业务的正常运行是处理故障的一个原则,即使无法迅速定位到故障的根本原因。 9. 重点强调快速收集故障现场必要的信息,即使无法迅速定位到故障的根本原因,也要在第一时间恢复业务的正常运行。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《MySQL 运维实战课》
新⼈⾸单¥59
立即购买
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
显示
设置
留言
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部