企业网站赏析中信建设有限责任公司国内区事业部执行总经理廖鸿韬

故障表现

• 他的执行时间超过规定的限制（比如1000ms）
• CPU使用率高
• 大量业务失败，数据连接异常
• 执行sql越来越慢，失败越来越多

解决方案

定位 + 应急 + 故障恢复

定位

• 查询慢sql的日志
• 查看mysql 的performance schena（里面有锁和各种状态）和show processList
• 是否请求出现请求积压，是否数据库执行时间是否快速增加，出现超时
• 获取故障日志，查看异常的原因（是too many connection，还是超时）
• 查看连接池申请的连接数据量，并且定时查看。看是否连接数暴增，是否有连接数泄露的问题。还有是否有服务异常的使用了过多的连接数。
• 假如有缓存的话，是否出现缓存穿透、缓存雪崩等故障
• 如果存在主从多个节点的话，定位是否是单个节点出现故障/性能问题而导致异常，是否有某个节点登录不上
• 查看对应服务的日志量是否大量增加，请求的qps是否爆发性增长（由于用户压测、节假日高峰期、活动导致的qps瞬间增加）
• 是否有运维故意的写错sql、删库或者其他行为，导致数据库本身出现问题
• 是否有节点状态异常、重启、切换等（mysql添加心跳检测）。当节点挂的多的情况下，可能会导致其他节点受到太多的业务压力，从而导致节点异常连环崩溃

应急：

• show processlist，持续的杀掉慢查询的语句
• 对慢查询的sql进行溯源，定位调用方IP，然后直接封禁掉对应IP的地址
• 查询数据库节点对应的cpu占用 + 内存占用 + 磁盘占用
• 对数据库进行切流
• 扩容数据库副本数（这个没做过）

故障恢复

• 是否对高峰期的sql进行限流（需要改动代码）、熔断、降级
• 在可能的高峰期估算可能的qps，并申请设备、留足余量
• 优化sql + 索引，替换慢查询的语法
• 对数据进行反范式编程，允许一定的冗余以适应查询时间
• 对过期数据进行清理，或者将历史数据更换到其他数据库
• 备份binlog日志，然后对binlog进行解析，看sql占用时间
• 添加普罗米修斯等监控，保证数据库的成功率
• 对核心数据丢失进行人工补救