1. 美团数据库自治服务平台建设 沈裕锋 1

2. 自我介绍 沈裕锋 美团数据库技术专家 曾就职于IBM、微软数据库平台团队，有多年的关系型数据库跟大数 据平台研发经验。 2019年加入美团，目前深耕于数据库自治服务领域，负责公司数据库 研发中心数据库自治服务（DAS）平台的相关工作。 2

3. l 背景介绍 l 平台演进策略 l 异常发现与诊断 l 自动化故障处理 l 未来展望 3

4. 系统背景介绍 美团数据库自治服务（Database Autonomy Service）系统是一种基于大数据技术、专家经验以及机器学习来实现数据库自感知、 自修复、自优化、自运维的服务平台，目标是快速的数据库异常发现、诊断跟性能分析、调用处理系统进行故障的快速恢复跟性能 优化。 运维效率 1. 分析定位难度高，以人为主，工具为辅 2. 工具之间联动少，单点之间来回切换 3. 处理过程不透明，协同沟通成本高 业务稳定性 1. 故障处理周期长，小问题容易变成大故障 2. 故障出现频次高，新业务故障持续不断发生 规模增长与运维能力发展之间的不平衡问题凸显 4

5. l 背景介绍 l 平台演进策略 l 异常发现与诊断 l 自动化故障处理 l 未来展望 5

6. 平台演进策略 整个数据库自治服务平台的演进路线分为可观测性、异常发现、诊断&处理、运营&治理几个大的阶段进行。 各层功能介绍 l 接口与展示：展示平台的功 能以及对外提供平台的服务。 l 业务逻辑层：使用采集到的 数据来提供异常诊断、SQL 性能优化与治理等业务功能。 l 计算存储层：通过实时计算 跟大数据平台对采集的数据 进行计算跟存储。 l 数据采集层：采集异常诊断 跟性能优化的关键数据，为 业务层服务。 6

7. l 背景介绍 l 平台演进策略 l 异常发现与诊断 l 自动化故障处理 l 未来规划 7

8. 异常发现与诊断系统 背景：数据库系统发生异常时，需要快速发现异常、根因定位以及快速解决问题，防止异常造成故障，影响并被进一步放大。 关键指标异常 异常类型 • 活跃会话突增 • 主从延迟增加 • 慢查询数量突增 • 其他异常类型 异常发现、诊断、处理的全生命周期 诊断面临挑战 • 造成异常的原因众多 • 全方位的信息获取困难 • 排查经验难以传承 8

9. 异常发现策略 根据不同的指标历史变化规律，构建不同的模型进行异常检测，根据历史的时序数据分布来预测未来的指标走势。 9

10. 异常诊断策略 例子：诊断主从延迟（seconds_behind_master）增大的规则列表 • 学习专家经验：咨询DBA同学以及学习 SOP文档，学习行业专家的经验； 顺序 规则名称 触发条件 1 slave_checkpoint_period太 大 slave_checkpoint_period >= 延迟告警阀值 * 50% • 内核源码分析：深入研究MySQL内核代 码，了解SQL执行的明细步骤，从最底 层的逻辑来判断异常发生的根源； 2 系统时钟偏移 |从库当前时间 - 标准时间| >= 延迟告警阈值 * 50% （|XX| 表示取绝对 值） 3 执行MASTER_DELAY SQL_Delay数值 >= 延迟告警阈值 * 50% 4 主从切换 检查高可用系统是否存在主从切换事件 • AI算法诊断：学习业界知名公司异常诊 断方面论文，使用AI算法来弥补前两者 诊断能力的不足 。 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 硬件故障 硬件检查平台进行检查 分析 规则生成 复盘 提炼 总结 10

11. 内核可观测性 背景：有些case的根因是很难诊断的（比如内核层面的Mutex阻塞造成SQL执行倍卡住），经排查发现SQL在内核 执行过程中某些关键的耗时数据缺失了，整理了整个SQL的明细执行步骤，同时MTSQL内核团队合作，输出了 100多个在内核中执行的关键步骤的耗时情况，为诊断打下坚持基础。 11

12. 内核可观测性 MTSQL内核团队对整个SQL的执行流水（包括全部SQL流水跟活跃会话）中涉及的关键步骤的耗时打点，对重要的 OS跟MySQL指标数据输出至本地文件，后经DAS传至后端进行SQL的性能分析与根因诊断。 MySQL内核数据采集上报架构 部分内核指标列表 • BPWaitFreeTime • SchemaWaitTime • BinlogRotateTime • RecLockTime • PageReadTime • LockTime • CommTime • PageWriteTime • TableWaitTime • TableHoldTime • SchemaHoldTime 12

13. 诊断系统架构与产品展示 根据专家经验跟内核可观测性功能总结出诊断规则，同时结合AI算法进行异常指标的根因诊断分析。 基于规则的根因诊断处理流程 基于AI算法的根因诊断处理流程 基于规则诊断给出根因（基于页面的产品展示） 基于AI诊断给出根因（基于IM的产品展示） 13

14. SQL性能优化&治理- 治理阶段 研发同学对SQL执行性能非常关注，希望在生产环境执行的SQL都是性能良好的；对SQL执行的整个生命周期进行监控，分 为事前、事中、事后三阶段来治理，及时发现风险SQL，进行索引优化或者SQL改写建议，提高SQL执行效率。 治理阶段拆解 事前（审核） 事中（实时发现） SQL发布生 产环境前 防患于未然，把问题 SQL扼杀于在摇篮里 SQL生产 环境执行 过程中 实时发现正在执行的 问题SQL，快速止损 事后（治理） SQL生产环 境执行过后 基于整体维度进 行SQL治理 14

15. SQL性能优化&治理-治理策略 如何进行风险SQL的治理？一般分成三个阶段，分成：发现风险SQL、分析风险SQL、给出治理方案。 发现问题 SQL请求耗时分布 服务耗时组成 网络耗时 业务逻辑耗时 访问数据库耗时 SQL执行可观测性 • 通过慢查询SQL跟全量SQL系统，发现有 性能问题的SQL。 GC耗时 其他组件耗时 给出方案 • 对于有性能问题的SQL给出如何添加索引 的优化方案。 SQL性能问题可能的原因 SQL恒定很慢 SQL逐渐变慢 SQL突然变慢 SQL忽快忽慢 SQL优化建议系统 治理风险 SQL治理系统 • 针对给出的方案，有风险SQL通过手工或 自动化的方式进行治理。 15

16. 发现风险SQL-全量SQL与慢查询系统 通过采集并且上报全量SQL以及慢查询日志信息（日志包含SQL文本、锁等待、执行耗时等信息），发送至平台后端用来 进行SQL相关的性能排查、优化建议以及数据安全审计等场景。 全量SQL系统架构 系统挑战 序号 挑战项 设计原则 1 QPS特别高（达到数千万/秒） 高并发、高吞吐、可扩展 2 数量存储容量特别大（PB级别/天） 低成本 3 业务需求变化频繁 灵活性 4 采集程序频繁更新，对MySQL实例影响大 低风险 5 后端处理逻辑复杂 可扩展 慢查询系统架构 16

17. 给出优化方案-索引优化建议 通过SQL可观测性能力发现有性能问题的SQL后，如何给出最佳的索引建议来提升SQL性能是一个具有挑战性的问题。 问题SQL类型 • SQL执行时间过长 • SQL扫描行数过多 面临的挑战 • 加或者不加索引是一个具有挑战的问题，因为相同的SQL模 版不一定都需要加索引，是否需要加索引是由数据分布来决 定，增加了判断难度。 待SQL优化例子，假设表的行数为10000 编号 SQL文本 是否加索引 列值 行数 1 select * from t1 where c1=1 Y 1 1 2 select * from t1 where c1=2 N 2 10000 17

18. 索引优化建议-系统设计 优化建议平台总体架构 核心思路 候选索引生成 统计信息采集 Cost重新评估 推荐最佳索引 18

19. 索引优化建议-基于workload优化建议 我们知道索引并不是越多越好，最好的方案尽可能使用最少的索引数量，同时能取得整个数据库系统的最大的性能提升， 这方面我们参照业界的论文进行了基于workload的索引优化建议。 核心思路 贪心算法索引选择 冗余索引合并 多伦枚举迭代 19

20. 索引优化建议-生态建设 通过索引优化建议服务给出优化建议后，需要在真正添加索引前后，进行事前的性能评估以及事后的性能跟踪，让用户事 前放心的添加索引，事后量化的感知优化的真实效果。 优化建议生态系统 索引添加前，让用户放心的添加DAS给的索引优化建议 索引添加后，让用户量化的感知添加索引带来的性能提升 20

21. 索引优化建议-产品效果展示 索引推荐 添加索引优化前后，SQL执行时间效果对比 21

22. SQL审核（事前） 在CI/CD平台集成流水线中增设SQL审核卡控，杜绝风险SQL被带到生产环境引发故障，起防患于未然的作用。 SQL审核流程 产品展示审核结果，风险提示跟建议 22

23. 实时风险SQL发现（事中） 风险SQL耗时分布图 耗时突增 耗时波动 间歇性慢查询SQL发现系统架构 耗时渐增 非风险SQL耗时分布图 全表扫描、新增慢查询风险SQL发现系统架构 耗时平稳 耗时渐降 耗时突减 23

24. SQL治理（事后） 通过批量分析已执行过的慢查询SQL跟全量SQL日志，给可优化的SQL提供索引优化建议，来推送给用户进行风险SQL的治 理，防患于未然。 SQL治理总体架构 l l 通过全量SQL&慢查询SQL日志获取SQL治理对象。 基于优化建议服务给出索引优化建议，通过风险治理系统进行风险治理。 24

25. l 背景介绍 l 平台演进策略 l 异常发现与诊断 l 自动化故障处理 l 未来展望 25

26. 诊断与处理系统分工 数据库自治服务：提供精确的故障根因，根 据诊断结果来快速、安全、可靠的执行某些 操作恢复故障是一个挑战，借助兄弟团队预 案处理系统解决问题。 预案处理系统：为DAS等服务的接入提供便 利，助力提升上述系统的一键化、自动化水 平，降低治人工介入成本。 26

27. 诊断与处理系统融合 数据库自治服务系统给出故障的根因或者SQL索引优化建议后，我们通过一键化或者自动化的方式调用预案处理系统处理 异常或故障，让系统快速、安全、可靠的从故障中恢复。 27

28. 产品展示 下面为系统诊断出根因后，通过调用预案处理系统的预案接口来对SQL进行限量、Kill阻塞者SQL或者添加索引的方式让系 统快速从异常中恢复。 28

29. l 背景介绍 l 平台演进策略 l 异常发现与诊断 l 自动化故障处理 l 未来展望 29

30. 未来展望 当前平台已经具备了数据库故障自助能力跟一定的自治能力，但是自治化、智能化程度不够高，没有完全形成闭环，所以数 据库自治服务的下一个目标实现完全的自感知、自修复、自优化、自运维、自安全的数据库智能自动驾驶平台，同时随着 ChatGPT的兴起，我们也在探索LLM（大语言模型）在智能运维方面的场景落地。 平台演进阶段 手工 通过手工输入 命令，进行故 障排查、性能 优化 工具化 平台化 海量数据的采 集、分析、给 出故障根因、 优化建议 通过开源工具进 行故障排查、性 能优化 自治化&智能化 自动弹性扩容、 自动维护索引、 自动参数优化、 自动空间优化、 LLM（大语言 模型）在智能 运维方向探索。 已实现 进行中 30

31. Q&A 31

32. 32