数据库异常智能分析与治理

1. 数据库异常智能分析与治理演讲人：蔡金龙@美团

2. 数据库异常智能分析与诊断蔡金龙@美团

3. • 现状与问题 • 解决的思路 • 技术的方案 • 取得的结果

4. 现状与问题实例高速增长带来的稳定性问题运维效率 1. 分析定位难度高，以人为主，工具为辅 2. 工具之间联动少，单点之间来回切换 3. 处理过程不透明，协同沟通成本高业务稳定性 1. 故障处理周期长，小问题容易变成大故障 2. 故障出现频次高，新业务故障持续不断发生团队口碑 1. 用户投诉多，产品满意度评分低规模增长与运维能力发展之间的不平衡问题凸显

5. 现状与问题理想很丰满，现实很骨感异常预防分解+逻辑转换异常处理异常复盘／改进 • 每个环节具备10%～20%的能力，保障能力短板明显 • 自助化和自动化能力不足，整个链条没有打通，未形成合力

6. • 现状与问题 • 解决的思路 • 技术的方案 • 取得的结果

7. 解决的思路既解决短期矛盾，也立足长远发展（Think Big Picture, Think Long Term）从历史故障复盘来看，有80%的故障80%的时间花在分析和定位上。因此，短期解决异常分析和定位效率ROI最高。长期来看，只有完善能力版图，才能持续不断的提升整个数据库的稳定性保障能力

8. 解决的思路夯实基础能力，赋能上层业务，实现数据库自治欲伐大木，岂能骤折。必以斧斤伐之，渐至微细，然后能折。--雄才大略的清太祖努尔哈赤“伐树理论”

9. 解决的思路建立科学的评估体系，持续的跟踪产品质量美国著名管理学者卡普兰说过“没有度量就没有管理” 运营指标拆解核心指标产品自治

10. • 现状与问题 • 解决的思路 • 技术的方案 • 取得的结果

11. 技术的方案技术架构的顶层设计设计的7大原则安全性：对业务影响极小，几乎可以忽略不计丰富性：系统覆盖历史上出现过故障场景所涉及的异常指标实时性：秒级以内的延迟，实时分析和汇总完备性：数据上报，不要错报，不要漏报易用性：掌握简单数据库知识即可使用，面向小白而不是专家可闭环：分析准确，决策正确，执行明确低成本：极致的数据压缩

12. 技术的方案采集层：慢查询采集设计慢查询：对于日志采集agent来说，准确率、延时、资源消耗三者不可兼得

13. 技术的方案采集层：全量SQL采集演进策略、技术方案和技术实现演进策略方案调研技术实现

14. 技术的方案采集层：摸底测试与丢失率优化

15. 技术的方案采集层：CPU利用率分析与优化用pprof工具对进程CPU占用进行了画像分析，从左边的火焰图归纳出CPU消耗的大头

16. 技术的方案采集层：CPU利用率分析与优化脱敏优化：脱敏下沉，功能解耦延迟脱敏的结果 rds-agent QPS 丢失率 CPU利用率改进前 50833.50 63.95% 601.39% 改进后 51246.47 31.95% 259.59%

17. 技术的方案采集层：CPU利用率分析与优化 1. 缩短链路: 分流、worker、解析SQL合并成一个goroutine解析器 2. 主动切换：解析器每5ms从网络协议包的队列中取一次效果 QPS 丢失率 CPU利用率改进前 51246.47 31.95% 259.59% 改进后 51229.54 0% 206.87% 链路优化的结果

18. 技术的方案采集层：CPU利用率分析与优化 GC优化：内存管理池化 rds-agent QPS 丢失率 CPU利用率改进前 51229.54 0% 206.87% 改进后 51275.11 0% 153.32% 池化的结果

19. 技术的方案采集层：CPU利用率分析与优化协议优化：过滤无用的空包过滤的结果

20. 技术的方案采集层：CPU利用率分析与优化优化前后数据对比

21. 技术的方案计算存储：大数据通道的建设与优化具备能力：支持大于10万实例的数据采集能力设计原则 1. 2. 3. 4. 5. 全内存计算：尽量确保所有的计算都在单线程内\单进程内做纯内存的操作，追求性能跟吞吐量的极致最小化对MySQL实例的影响：尽量计算后置，不在 Agent上做复杂计算，确保不对RDS实例生产较大影响上报原始数据：MySQL实例上报的数据尽量维持原始数据状态、不做或者尽量少做数据加工数据压缩：由于上报量巨大，需要保障上报的数据进行极致的压缩内存消耗可控：通过理论和实际压测保障几乎不可能会发生内存溢出

22. 技术的方案计算存储：分钟级别的数据聚合 Mafka Consumer线程对相同模板SQL的消息按分钟粒度进行聚合计算，以（RDSIP+DBName+SQL模版ID+SQL查询结束时间）所在分钟数为聚合键，聚合健的计算公式为aggkey=RDS_IP_DBName_SQL_Template_ID_Time_Minute （Time_Minute的值取自SQL查询结束时间所在的“年、月、日、时、分钟”）

23. 技术的方案计算存储：过期数据的补偿机制

24. 技术的方案计算存储：避免跨机器的开销，使性能跟吞吐量达到极限

25. 技术的方案计算存储：日均千亿级SQL的极致压缩遵循层层减流原则，使用消息压缩、预聚合、字典化、分钟级聚合的手段，保证流量在经过每个组件时进行递减，最终达到节省带宽减少存储量的目的

26. 技术的方案能力评估指标体系

27. 技术的方案基于数据驱动的异常分析和根因定位的顶层设计参考： https://mp.weixin.qq.com/s/QMbsV1609NVx60zI1CKffw

28. 技术的方案主从延迟规则展示顺序分析决策：规则的提炼 300+异常告警复盘，深入的内核原理分析回顾提炼复盘总结分析规则生成规则名称触发条件 1 slave_checkpoint_period太大 slave_checkpoint_period >= 延迟告警阀值 * 50% 2 系统时钟偏移 |从库当前时间 - 标准时间| >= 延迟告警阈值 * 50% （|XX| 表示取绝对值） 3 执行MASTER_DELAY SQL_Delay数值 >= 延迟告警阈值 * 50% 4 主从切换检查高可用系统是否存在主从切换事件 5 库迁移操检查迁移服务是否存在库迁移事件 6 主库大事务 (主库事务执行 > 20s || 主库事务影响行数 > 100000) && 从库复制线程出现该事务 7 MDL锁阻塞从库复制线程state出现waiting for XXX lock 9 主库写流量突增从库写QPS突增 || 从库Innodb_rows_XXX突增 || 从库Innodb日志写入量突增 10 未启用并行复制从库slave_parallel_workers == 0 11 从库读流量突增读QPS突增 && cpu load突增 && IO利用率突增 && 本机慢查突增 12 从库出现大查询读QPS不突增 && IO利用率突增 && innodb_rows_read突增 && SQL执行时长>20s 13 实例重启从库Uptime < 60s 14 IO/SQL线程重启从库MySQL运行日志中抓取特征文本 15 硬件故障硬件检查平台进行检查

29. 技术的方案以铜为镜，可以正衣冠；以史为镜，可以知兴替；以人为镜，可以明得失

30. 技术的方案验证是改进的基础，持续验证，持续改进

31. • 现状与问题 • 解决的思路 • 技术的方案 • 取得的结果

32. 取得的结果分析决策：指标评估（基于异常告警） 70% 99% 80% P0覆盖率帮助率召回率 80% 准确率

33. 取得的结果目标回顾与用户反馈用户问卷调查

34. 取得的结果客户案例会话触发告警分析+拉群根因定位

35. 取得的结果客户案例延迟触发告警分析+拉群根因定位

36. THANK YOU!