软件架构自学笔记– 转载“腾讯数据库专家雷海林分享智能运维架构”

2019 年 5 月 8 日 -10 日的 DTCC2019 年中国数据库大会上，腾讯云数据库专家工程师雷海林首受邀做了主题为《TDSQL 智能运维平台 – 扁鹊架构与实践》的技术分享，以下为大会现场演讲实录。

针对这些问题，我们认为需要一个自动化的故障 / 性能问题分析系统，减少 DBA 的重复劳动，沉淀我们的分析经验，快速定位问题，带给我们的客户最快速的响应同时也提升 DBA 的幸福指数。

之所以将这个模块命名为扁鹊，就是希望它能像古代的扁鹊神医为人诊断病因一样也可以为数据库“对症下药“，治疗 / 修复 / 预判数据库已知或潜在的风险。

2. 扁鹊的作用

在开发扁鹊系统的时候，随着 DBA 的专家知识库不断向扁鹊输入，目前我们大部分现网的性能 / 故障问题基本都可以通过我们扁鹊一键分析原因，大大解放了 DBA 的双手，极大提高了运营效率。下图是我们对扁鹊在设计阶段所设定的基本功能和目标，核心点就是希望扁鹊能做到风险事前预警，事中准确分析原因并解决问题，事后能对历史事件进行分析，发现问题点。

下图展示了扁鹊更细化的结构，可以看到扁鹊具备了哪些功能，这些功能需要哪些元数据，元数据又从哪些层面获取，各模块之间如何交互等，如果大家要做类似的功能可以基于这个做一个很好的参考。

引起切换的原因有很多，这里我们列举了一些常见因素，如触发了内核某个 bug 导致 DB 重启 hung 住，磁盘故障导致 DB 无法写入。也有可能是由于用户的一些 SQL 过度的占用一些 CPU、IO 等资源导致的，如大事务，慢查询并发影响到用户或心跳线程写入等等。

从我们自身的运维经验来看，由 DB 故障导致的切换并不常见，更多的情况是由于用户的 SQL 占用过多的系统资源引发的一些异常状况，主要可以分为慢查询并发和大事务两类，下面我们逐个分析两种行为触发切换的原因

由慢查询并发引起的主备切换

TDSQL 默认采用 innodb 存储引擎，在 innodb 中为了避免同时在 innodb 中同时运行的线程过多带来额外的性能开销，innodb 提供了一个 innodb_concurrency 的参数，用于限制同时在 innodb 中执行的线程数的最大值。搜索关注腾讯云数据库官方微信，获取更多数据库技术干货分享，体验移动端一键管理数据库。如果客户执行了用大量的并发连接执行慢查询，这些慢查询会不断地占用 innodb 的活跃线程，导致用户很多访问 innodb 相关的操作简单插入 / 更新等操作也容易被阻塞，等待 innodb 处理，同样也会引起 agent 心跳检测不断失败，从而触发主备切换。

当这种情况发生时，我们可以看到 innodb status 信息中有大量的线程处于等待队列，并且有很多慢查询在 processlist 中执行和很长时间，这样我们就可以分析事先保存的 innodb status 信息确认这一现象，再结合 processlist 中找出 TOP 慢 SQL 就可以知道是哪些慢查询并发导致了这个问题。

扁鹊的自动化分析效果

结合上述分析流程，扁鹊会自动化的针对监控，切换前的 DB 快照等信息分析出切换的原因，并展示详细的分析过程。

1). 下图展示了扁鹊分析出由于 DB 发生不存活引发了主备切换

3). 这里我们看到扁鹊定位到了由于大事务引发的主备切换，并找到了引发大事务的具体 SQL

SQL 自身执行较慢

对于 SQL 自身执行较慢通常是由于用户没有建立合适的索引，或者由于一些 SQL 写法上的原因导致没有利用到已有的索引，扁鹊针对这种 SQL 会自动的通过语法解析，SQL 访问的表结构，数据分布等信息进行分析，生成合适的索引优化建议反馈给用户。搜索关注腾讯云数据库官方微信，获取更多数据库技术干货分享，体验移动端一键管理数据库。

锁等待

引起 SQL 请求时耗高的另一大常见因素是锁等待问题比如事务 1 中一个会话更新了一行，但是事务还没有提交，这时另一个事务 2 的某个 SQL 去更新同一行就需要等待事务 1 提交完成才能执行，这其中等待的时耗也会导致整个请求的时耗增加。这种情况下用户的可能会发现部分简单的操作例如主键更新正常情况下都是 0ms 的，偶尔突然变成了数十秒，当客户反馈给我们后，发现 SQL 执行时耗可能又正常了，下面我们看一下扁鹊如何辅助客户 /DBA 分析这类问题。

对于这种情况只要客户的 session1 不提交事务并且不与 DB 断开连接，这个会话持有的锁就会一直保持。MySQLinformation_schema 下有三张表记录了事务之间的锁等待依赖关系，如下图中 session4 不被其他会话阻塞，但 session4 持有的锁阻塞了 session1，2，3，这里我们称 session4 为持有锁的领头会话。这种情况由于锁等待现场环境还在，扁鹊就通过分析这三张表的信息可以找到持有锁的领头会话并建议用户 kill session4 来解除锁等待。

除了事务未提交以外，用户的业务逻辑也有可能在执行完事务中所有 SQL 后没有立即提交事务，导致事务持有锁时间较长。在下图中可以看到 session1 执行完 update t1 后隔了 50s 才提交事务，导致 session2 的 update 同一行操作的时耗也在 50s 以上甚至出现锁超时错误，如果用户在 15 点反馈 12 点某个时刻出现了这样的问题，我们再去查看 information_schema 下的锁信息内容会发现已经没有这样的锁等待关系了。搜索关注腾讯云数据库官方微信，获取更多数据库技术干货分享，体验移动端一键管理数据库。针对这种情况，我们只能通过用户执行过的 SQL 日志，来找出 session1 这个历史会话信息，那么我们面临的问题是

1. 从哪里提取 SQL 日志/li>
2. 如何通过用户提供的慢查询高效的找出 session1 这个历史会话信息/li>

如何通过用户提供的慢查询高效的找出 session1 这个历史会话信息/p>

虽然有了用户全量的历史 SQL 信息，但是我们仍然难以直接从日志中找到 session1 在某一时刻阻塞 session2 这种时间序列“交错”的会话信息，或者说是 session1 事务开始结束时间覆盖了某个时间点的事务信息。

这里扁鹊实现了一个事务模拟器，可以通过按客户端执行记录的 IP:PORT 分组并结合语法解析回放用户执行过的 SQL 来提取所有事务信息，如事务的开始，结束时间，事务中访问了哪些表，事务的影响行数，事务的总时耗等等，这样我们就可以通过设定过滤条件以事务为单位来找出某个事务具体的执行信息。

扁鹊通过设定 22:00:37，T01_NOR_CUST_INFO 这两个条件就可以自动找出事务执行时间包含 22:00:37 并且对 T01_NOR_CUST_INFO 有过 update/delete/insert/selectfor update 等可能产生行锁的事务，并自动的提示用户这个事务时耗过长，持有的锁时间过长可能影响其他会话这一异常信息。搜索关注腾讯云数据库官方微信，获取更多数据库技术干货分享，体验移动端一键管理数据库。有了这个功能，我们就可以根据用户提供的慢查询出现的时间点和 SQL 快速的找出影响的会话具体信息，用户就可以根据扁鹊提供的事务信息和时间来排查业务逻辑修复问题了。

对于 DB 潜在风险的排查，我们针对性能监控，表结构，历史会话，慢查询等信息结合腾讯云海量数据 + 机器学习的能力系统的评估 DB 的健康状态，检测可能的异常并告知客户，尽可能将大部分异常在发生之前就发出预警，将风险降到最低。

四、总结

以上我们介绍了由 TDSQL 运营痛点催生扁鹊的需求背景，以及扁鹊的层次结构，组成元素，还有主备切换，锁等待分析等关键技术的诊断原理，实践经验。拥有扁鹊后在公有云性能类咨询工单已经基本降为 0，可以看出扁鹊目前的功能已经可以很好的服务于我们的客户也提升了我们 DBA 同学的生活品质，未来我们也会继续完善扁鹊的诊断、预测能力，整合我们 DBA 多年的运营经验和 AI、机器学习等技术，覆盖更多的异常场景，争取做到将所有异常在发生前就预测到，为客户提供更安心的运营环境。

本文转载自腾讯云数据库

原文链接：

https://cloud.tencent.com/developer/article/1429232

转载于:https://www.cnblogs.com/1605-3QYL/p/11042028.html

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8679 人正在系统学习中 相关资源：基于java的GUI图形化界面的汽车油耗软件-Java代码类资源-CSDN文库

来源：weixin_30706507