故障表现
- 他的执行时间超过规定的限制（比如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占用时间
- 添加普罗米修斯等监控，保证数据库的成功率
- 对核心数据丢失进行人工补救
