视频 -RDS 常见问题排除及 DAS 自动弹性伸缩（二）| 学习笔记-阿里云开发者社区

开发者学堂课程【企业运维训练营之数据库原理与实践课程：视频 -RDS 常见问题排除及 DAS 自动弹性伸缩（二）】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1201/detail/18302

视频 -RDS 常见问题排除及 DAS 自动弹性伸缩

三：三大场景介绍

1. 场景1：连接类问题——连接不上，连接报错

我们现在开始关于场景 1 的介绍。对于连接类的问题，我们要重点清楚整个访问链路是怎么样的。比如访问链路就涉及到客户端到服务端的网络和服务端，服务端是指我们这的 RDS 。具体的我们就需要清楚从哪里发起链接，用的什么 RDS 链接地址，从哪里发起链接，明确我们的客户端在哪里，比如我们的阿里云EC，一个网络的连通性，或者是不是有额外的限制导致我们无法连通。这是大家需要考虑的。比如我们在 ECS 上，ECS 所在的地域，ECS 设置的安全组或者是不是设置 IP tables或者本地比如IDC，是不是在防火墙上有一些规则限制等。这些可能都会影响到我们连接访问。在 RDS 上也有，比如需要添加安全组或者白名单来保证我们客户端可以进行访问。这就是第二点，我们要保证我们在相应的配置上，能够让选定对应的网络类型之后进行一个访问。第三，在我们网络是通的，连接地址也选对的情况下，比如使用的数据库的账号密码，还有数据库的连接数是不是有相应的限制打满，导致我们连接不上的情况也是需要去考虑的。总结即我们的客户端到 RDS 之间的网络，以及 RDS 这三者如果任意一个配置不合理或选择不合理，就会导致我们无法连接或者是连接可能出现问题。我给大家在这总结了相应的信息，这可能也不是包含全部的，比如可能还有一些更细的影响因子，比如有时客户有的客户他可能使用 VPN 访问式去访问，他可能去设置的 MQ 设置的不匹配也可能会导致连接之后可能无法执行，无响应的状态。

介绍完影响连接的因子，再来说可能访问异常的现象有哪些。对于我们连接时是一直报错还是突然连接不上报错或者是偶尔连接不上报错，对我们去排错的时候也是需要去确认的。对于一直连接不上，我们需要检测网络是否连通，多出现在刚购买实例第一次连接时，此时重点检查网络的连通性，比如连接地址是否正确，网络连接是否做了相关配置打通。这就是刚才给大家提到第 1 点和第二点需要确认的。如果是对于突然连接不上，也是需要检测网络连通性的，在网络不通时，需要检查一下我们的比如安全组，白名单的这些变更是不是有做相关的变更导致我们突然连接不上。在网络连通的情况下，可能需要检查客户端和服务端的情况，比如实例的负载，客户端到服务端网络在通向客户端比如配置的连接池是否耗尽，服务端的连接数是否打满，或者服务端 CPU 打夯，这也都可能影响我们突然连接不上的情况。如果是偶尔连接不上，可能会出现这种网络连通性上来说可能就不存在问题。可能更重要是中间的网络上或者在客户端或者服务端一些配置可能会出现一些问题，比如服务端的可能配置的 timeout 参数不合理，导致空闲连接太久之后服务端把连接给断开，客户端再次去拿链接时，可能就会出现报错的情况。这种我们需要去部署一个循环抓包的命令去在程序上部署。当出现后，我们可以及时通过去分析报文去查看相应的问题。

对于 3 种连接异常现象，我这里就是介绍 5 个命令，用于诊断网络连通性、稳定性和连接报错。它们分别是 ping ，Telnet，traceroute ，mtr ， tcpdump，对于一直连接不上或者突然连接不上，我们就首选要使用 ping 和 Telnet，先确认网络连通性。如果是偶尔连接不上，我们可能就要使用 traceroute ，mtr ， tcpdump 来判断一下网络情况，比如中间是不是可能存在这种丢包比较严重的这种情况，我们就可以通过后面的工具来协助分析定位。

下面介绍这 5 个命令，我可以和大家做一些演示，希望大家能够掌握相关这5个命令的使用方式。特别的是对于偶尔连接报之后，大家一定要养成习惯，提前去部署好这种抓包。当复现问题的时候，第一时间把报文可以反馈给我们，帮你们确认。Ping 命令，它可以确认我们是否能够正常解析域名网络时延是怎样的。比如我在去拼域名地址时，它可以把对应的解析的 ip 地址可以拿到， ip 地址是否正确？因为有些场景比如我们在本地做了一个本地解析比如像 RDS 实例，它可能做了一些变更，导致底层的 VIP 发生变化，如果还在本地做了一个硬解析，可能你拼的地址还是之前的IP，你连接过去它还是对应的以前 IP，可能就会导致连接不上情况。所以 ping 我们是可以关注解析 IP 和时延。在我们之前讲课里面提及，比如在 RDS 上可以，对于像 Redis 这种内存型数据库，它对这种网络时间特别敏感，当我们实例比如从 ECS 到比如 RDS 的 SDB ，到我们的后端的 DB，它整个链路它如果出现这种跨可用区访问它，这个时延可能就会增加。一般来说当跨可用区的时候，ping 的延迟可能会出现 3 毫秒内的一个延迟。所以我们通过ping 延迟需要留意一下我们时延时的情况是怎样的。 Telnet，在我们连接不上的情况下，也需要使用 Telnet 去检查端口是否连通。需要注意使用Telnet时，加域名的后面需要跟上数据库的端口，比如 RDS 默认的是3306，如果我们在 RDS 控制台做了相关端口修改，这也要指定成正确修改后的端口。如果是类似于这样的返回，就证明 Telnet 网络上是连通的。和大家延伸解释一下，我们在做 RDS 侧，白名单拦截的时候，实际上有两种方式，一种是在 SOB 上做的，一种是在 DB 上面做的。在 SOB 上做我们可能直接就贴入，有可能会出现 q 类能通的情况，会看到返回但实际去连接它是无法连接的。所以要注意并不是我们显示返回就表示一定是加白名单的。我们没加白名单，因为它实现的机制可能会有两种可能。有时候能够 Telnet 的连通显示但实际上它没。发现这个 IP 是未在白名单里面，它能 Telnet连通，但是它实际连接会被 DB 拒绝。第三个命名就是关于 MTR，它可以追踪数据包的传输，使得全部路径是不是中间有出现丢包的情况。比如我们平常一般会添加 -n 来避免反解析。 -c 我们可以指定发送数据包数，report我们可以以报告的形式。在第一列是显示我们节点，第二列是相应的节点对应的解析的 ip 地址，第三列是显示的丢包率，第四列是每秒发送的数据包即我们-c 指令的值。第五列是关于最近探测的延时值。后面是平均的最好和最差还有标准方差，如果值越大就证明节点的稳定性可能不太好，可能会出现问题，比如像20% 偏差会有一点大，可能有些丢包，在此截图其实良好，只要它不是在某一跳之后持续性的丢包基本上都问题不大。Traceroute 是可以追踪我们数据包的传输时延的全部路径和时延的情况。这里其实可以看到它在一条路径它每个设备会 traceroute 测试三次，输出结果中会包含每次测试的时间和设备的名称。这里一般我们也会加上-n反解析，-t加上是走 TCP 协议，用 SYN 进行探测，默认我们是走 UTBA 协议，也可以只用指定-i走 SAMP 协议，我们如果走指定-p，走TCP，我们可以指定具体端口号。

tcpdump 我们可以用于抓比如网络重传，网络连接抖动时，我们可能用会用到 tcpdump。 tcpdump 一般我们在 linux mime 下就会用，比如你如果是 windows，你可以用这种 wireshop 去抓。一般绝大多数是 linux 环境部署的程序。我们这里介绍一下 tcp dump 的使用方式。首先我总结 tcpdump 的使用的这种两类场景。一种是客户端程序报错日志，这种指向不明确，比如没有把原始的 Mysql 这种报错信息展示出。比如从报文里面看到直接用户名密码不对，但是你在可能程序打印的日志，因为它可能封装一些架构，或者自己去定义抛出的某个日志的时候，你可能去指定相应的做一些指令，它没有把原始底层的日志打印出，导致你去看到报错信息的时候，不明白它到底是哪里出错，也可以通过抓包的方式去定位。

另外一种就是偶尔连接不上，比较疑难的场景中，我们经常也会用到 tcpdump。这用 tcpdump 一般也是分为两个步骤，第一个就是去抓取报文，第二步是分析报文。抓取报文需要大家平常遇到问题的时候，自己去部署抓包命令去抓取。如果在分析报文上，比如连接我们 RDS 出现这种抓取到这种报文的后续又没分析能力的情况。你也可以把相关报文在提交工单的时候跟我们一并反馈，能让我们快速地去通过你的报文去帮你分析相关的问题。

这里面抓取报文的时候大家需要注意 3个点，一是 tcpdump 要部署在连接问题所在的主句上，第二是要出现问题前就要开始抓包，出现问题后再停止抓包。你要保证你的报文中是出现异常时的报文。最后最好程序把报错精确到秒级的时间也需要打印出。因为经常有些时候客户他可能只给我们提供报文，或者只提供日志。日志它这个时间戳不是特别细，比如它只是到一个时分，没有到秒。我们分析报文是希望时间是越细越好，能够更进一步地帮助我们去定位相关的问题。

第三点是对一种低级频报错的场景提前部署这种循环抓包的方式。但是去循环抓包要避免单个报文过大的情况，比如上面是给大家列举具体使用的循环抓包的命令。- i 比如是指定端口，-s我们可以选择让- s 为0，可以自动选择合适的长度来抓取数据包。-w，我们可以把抓取帮我们输出放到文件里面。-c，我们就可以指定文件的大小，比如像这-C 100是100 兆。

-w 指定文件个数是多少？比如是五个，后面我们可能会循环覆盖，循环写这五个文件。所以保存个数和大小一定要根据自己的场景要控制。平常去抓包部署，比如部署在程序所在的 ECS 上，也要保证抓包的文件不要过大，导致比如把ECS 的磁盘打满。所以在设置个数和大小的时候，一定要充分考虑，后面就指定需要抓的端口号。

我们刚才提到对于分析报文，我们平台也是需要大家能够提供相应的程序日志，这个日志也是需要精确到秒级。我们过滤报文的时候，就可以首先快速地过滤，一般比如有明显的 Mysql 错误码，我们可以通过比如 Mysql . error code 大于 0 去快速过滤，比如经常出现连接被重置我们可能就用 TCP Flex.reset=1 的方式去快速地这种过滤。下面给大家列一些错误码，大家以后遇到比如 error code，你看它大于 0 ，你可以不清楚它什么意思,你也可以快速地去看Mysql 的官方文档，看它对应的报错误码对应的含义是什么。

像这个截图里，我们可以看到它是服务端 3306 端口给客户端发的结束连接的报文，这和上一个时间相差有 30 秒。我们客户端设置 wait time out 参数，设置为30，他想要快速的去回收这样的空闲连接，在我们空闲连接达到 30 秒，服务端去回收连接的这样一个动作。

现在给大家做一个简单的演示，希望大家能够参考。比如我们 ping 可以看到，我这 CN， IP 这些是可以得到的。如果你拼得不连通，可能网络上也是有问题的，需要去检查。比如网络连通性是什么，拼的域名是否正确，都是需要去检测的。

有时我们在本地解析这种场景，我们再去 ping 的时候会发现它 IP 改变，但是这个时候如果我再去连接 RSD ，它指向的就是1.1.1，这时候我们再去连接是连接不上的，这就是 ping。

如果使用我们的RDS，首先要注意使用域名显示连接，最好不要配置本地的解析保证，保证 RDS 对应的 IP 发生变化的时候导致连接不上的这种场景。

对 Telnet，大家注意，现在我在使用 Telnet，它是 Telnet 不通，因为它去解析是按照本地解析，它是解析1.1.1。

这时如果把它去掉再去 ping，再去 Telnet，它是可以的，因为我已经提前在 RDS 上添加好服务器的白名单，它是可以 Telnet 的。

关于 MTR ，MTR 就是我们刚才说指定的是 report 形式，它是在全部探测完之后，才以报告的形式输出。大家看到 MTR 的时候，大家要关注什么？刚才除了所提，最重要的关注比如是否从某一跳以后持续性地出现这种丢包，如果持续虚拟的丢包，可能你需要再查看它标准篇章是不是在从第一跳开始，后面的是否比如这是百分之百，后面持续百分百。可能标准平台大概率是这个节点有问题，这个时候遇到如果你是走的这种外网，因为你走到外网环境，它是走到外部网络运营商的，你也可能就只能向网络运营商反馈。这个就是关于 MTR。

traceroute，大家遇到 traceroute 也是可以关注，只要后面不全是新联想，遇到比如它有可能中间的某个节点，它是做那种网络硬伤，他可能做屏蔽，不会返回数据，只要看他到最后的目标这一端，他还是可以运行的，这个基本上是没问题的。

这是关于 traceroute，我再给大家演示一下。给大家看关于报文的，比如我们需要过滤 Mysql 错误码大于 0 ，就能够快速地去通过这个方式过滤。

比如它可以得到你的最近 error code ， log time 也是同样的。比如给大家演示 RST ，我们平常比如你可以看得到也可以去对应的追踪对应的 TCP 流，你可以查看它的流里面请求是怎样的。比如它执行了一个 store，比如 30 秒之后它连接就断开，服务端给客户端断开。我们经常会使用这种比如过滤这种 RESET 的报文。

首先一般连接问题，首先我们就要去过滤有没有这类的报文，大家以后遇到这种抓包需要我们帮看，一定要把相应抓包的这种信息要反馈给我们，连接类的问题就介绍到这。

2. 场景2：只读实例复制延迟

关于场景 2 只读实例延迟的介绍。大家如果做数据库管理，比如平常自建数据库，我们可能经常会搭建这种子路，即重节点，或者称为子路节点来提供一个读请求给业务使用，来减少主库读的压力。大家在使用的指读实例的场景的过程中，有没有遇到过延迟的场景？大家如果在本地遇到这种延迟，大家如何去定位延迟原因，如何快速恢复延迟。我们在云上也会经常遇到客户提问题咨询这一类问题。通过这个场景介绍，希望能够大家理解复制的原理，知道引起复制延迟的常见原因分类。后面也会介绍一些命令，让大家知道对于大数引起的延迟能够快速定位，也希望大家在日常工作中也要尽量减少这种大事务类操作。在原理上，我们主从复制其实和开源 Mysql 也是一样。主库，它会通过一个 binlog dump 线程推送日志，备库通过 IO 线程连接，主库会接收日志并写入我们的 relay lock，再由 SQL 线程应用 relay log，保持一个主库同组重同步的关系。

我们在高可用实例上面一组一背，背景点之前介绍它只是提供一个高可用切换使用，并不提供读能力，业务如果需要实现读写分离，它会需要单独地去购买只读实例来提供这种读分单读请求。我们本次高可用的主备实例之间，其实是一个双向复制的关系，只是我们从库是不提供读写请求的。之前我们也提到过关于要开通指读实例，它首先必须是我们的RDS比如高可用版或者企业版，它才可以。这里经常有一个问题是我们如果平常 base 里如果出现一个复制延迟的场景，一旦这个时候我们主节点如果挂，我们就没办法切换到我们背节点来做快速恢复的动作。比如 HA 探测系统在进行探测的时候，它是需要探测我们主备实例延迟情况。当延迟太大，我们是不会去做切换的，除非有客户强制要求不怕数据丢失，需要你帮我强切，我们才可能帮客户做这类操作，但是也是需要客户充分授权的情况下，我们才能做这样的动作。

这类创建出来的子读实例和我们主实例是单向同步的关系，它也是从高 killer master 节点，所谓的主节点去同步，它并不是从被节点完成同步的。比如我们发生 HA 切换，这些子读节点也会重新调整复制关系，把它重新从新的主节点上去保持一个同步。另外我们有些时候会遇到有些客户的场景是比如可能通过 Flink 或者其他的Canal，可能会去消费主实力的 Binlog，这个时候可能会引起空间打满，比如我 RDS 里它清理本地日志空间的功能。如果有其它线程去占用相应的 binlog，导致清理线程无法把 binlog 清理的时候，可能导致主实例的空间出现不断增加，直至可能打满的这种情况是有遇到过。所以如果大家平常有通过第三方的工具去消费主实例的 binlog，也是需要注意。

关于延迟原因，我总结一些高频例如像数据库版本、网络等，它可能引起延迟，但是我没把它概括进。这里重点给大家介绍下面这几个高频影响问题的因子。一个是子路实际规格小，当我们 CPU 或者内存比主实力规格小的时候，它显然可能会成为资源，成为瓶颈，影响到复制。当我们子读实例规格负载比较高的时候，因为你的子读实例提供这种读访问，有一些慢查询，把子读实例的 CPU 打满，比如 LPS 打满的情况下，复制线程其实也是会受到影响的，也可能导致复制延迟的情况。另外大事物也是遇到很多的场景。比如有的客户批量删除 1000 万行数据，批量更新几百万行数据，在这种大事务操作没有意识到大事故可能会导致一些额外的风险。比如他没有增加指读节点，只有使用一个高可用实例，在做大事务没有充分考虑做实例时会出现的问题如出现踩bug，实例夯下掉，这时又由于背库延迟导致我无法切焕，所以这对业务上来说是一个有损的操作。所以平常我们去做这种大事务时，尽量要把它调整拆分成这种小事务来操作。

关于锁阻塞，锁阻塞基本很多时候是出现在场景比如在有的客户他做一些 DDL 变更，它把这个操作可能它在主实例上不一定出现了源数据锁，当我的只读实例拿到 DDL 语句，在只读实例上应用的时候，这个时候在应用之前有只读查询： snake 的查询，长时间在跑，就会导致 DDL 变更始终拿不到源数据锁，造成全局阻塞的情况。所以我们平常在主实例上做 DDL变跟后，也是需要关注我们只读实例是否有出现这种源数据锁阻塞的情况，这就是锁阻塞。

关于表无主键，它类似于大事务。当我们去做表无主键，对表做一些相应的操作时，比如 DM 操作，但我们子路实际上它是基于一个全表的扫描方式去更新，去删除，这就会导致表没有主键之后性能急剧下降的。所以我们在开发规范里要明确的给开发人员定义好规则：表必须要设置主键。

另外是关于参数，参数比如双击参数，比如双击参数 in a flash log 或x commit，或在 5. 71 和 8. 0 上有些 binlog transaction dependency tracking，它加比如 right side ，这种对于提高这种写入性能是很有帮助的。比如还会遇到有些客户，他可能把我们的 Interdb adaptive hash index 这个参数即我们所谓的自适应hash 索引开启的情况下，他可能也是做了一些 DDL 变更后导致我们子路实例去应用变更之后，它可能会需要清理内存当中的自适应hash 索引。这个时候由于是一个全局锁，它可能会导致实例出现这种短暂夯的情况，以此复制延时的情况，也是可能出现。所以目前来说，我们在新建实例上都是把参数置为 OFF 的，平常对于这种历史创建的实例，大家也可以去仔细评估一下，看是否把参数关闭。因为经过我们大量的客户反馈，目前看多场景都是风险大于收益的，可以考虑把参数 h i 给关闭。出现的原因这里跟大家介绍完毕。另外可能表结构设计上，因为有时可能有些客户喜欢把表设计成带有唯一索引，这种一般不建议在业务上，在数据库侧通过唯一性索引来保持键的唯一，最好是通过业务上来实现是更好的。

介绍关于延迟产生的原因浏览性，当我们出现延迟后，我们又该怎样快速的恢复？对于我们购买高可用子读实例，现在高可子读实例分基础版子读实例和高可用版指读实例，高可用版指读实例会在后台帮他创建一个相当于是容灾的只读实例。这样如果提供业务访问的只读实例故障，我们可以快速的帮你切换到备用子读快速去恢复，对于延迟场景，其实它是有一定的帮助的。因为我们只读实例备用子路是不提供业务访问，很多时候他可能去应用如你遇到的大事务，他可能执行的时间更短。这时如果你急于恢复，你可以找我们帮忙确认比如你备用子路是否已经没有延时，如果没有延时，我们就可以帮你快速切到备用子路做恢复。但是要注意切换动作和储备实例是一样的，做切换动作的时候，它是会有连接闪断，这个是需要注意的。另外一种快速恢复的方式如从主库上做一个流式备份，帮你直接重建一个只读实例，这时就需要注意当我重建的时候，后面就不能再有大事务的产生，如果你还有这种大事务产生，也会导致重建完去应用增量的 Binlog 时，还有大数量语句，就会导致整个新建实例的时间会很久。当然采用这种所谓的流式克隆尺度实例的这种方式也是会受限于比如是本地盘的实例，还是云盘的实例，数据量的大小，这些都是影响克隆时间的因素。一般来说也是建议一些客户使用云盘，ESC 云盘的实例，当我们去克隆时，因为它是云盘备份，能够快速的去帮你克隆一个实例。一般比如1T、 2 t 这种大小，一般也就半个小时以内就能够克隆出一个新的只读实例。所以如果不是对网络时间特别高要求的场景，一般还是可以考虑选择这种 ESC 云盘类型的实例。

在之前给大家提到一旦出现延迟，可能业务上就会明显地感知到延迟的影响。对于这种时延要求比较高的场景，如你接受不了比如 10 秒钟或者 30 秒钟的延迟，你是可以在读写分离的地址上去配置一个延迟阈值。某个节点超过阈值后，新的请求过来便不再会分给有超过延迟阈值的指数节点，会分发给其他节点。如果所有的节点延迟都比较大，它可能分发给子路节主实例，主实例可能就经受不住。这时大家需要格外关注小心。

前面介绍了复制原理，延迟原因以及如何避免延迟的产生，也提及一个 RDS 只读实例出现延迟的快速恢复方案和业务上如何避免读到过旧数据。现在我们讲如果出现大事务或者源数据锁，或者无主键表，这种的情况怎么去确认引起延迟的操作？

我们可以去通过修 slave standards 去执行多次查看，因为我们是使用 GTID 的全局唯一性事务标识。你可以看到我们接收到的 GTID 位点和应用的 GTID 位点。我们重点需要关注应用的 GTID 位点，比如是否卡在某个位点，如果连续执行多次，它的一直不动，卡在一个位点。如果你通过 show process ，类似于这种元数据锁阻塞的情况下它就是一个大事务，我们就可以往大事务的方向去排查。

第二查看这个事物的开始时间和会话状态，比如可以看 select，interbtrx，比如看事务执行的开始时间多久，去观察事务的操作状态是什么。Fetching rows，和大家强调如果大家看到为这个状态，大概率是一个表没有主键的情况，大家就要重点的去注意比如它卡在这个位点时，他有没有具体的相应的语句。可以去从主实例的慢日志，审计日志查看对应时间点的操作的情况。

三看具体的操作记录，我们首先还有是一些其他的动作比如想确认是哪一类操作影响的比较多，比如 insert ， delete ， update 。你可以通过 show global status like Interdb Zoss。可以去观察类似于截图里面，像它有大量的插入行为，比如用 DTS 同步，比如它使用 load data 方式批量写入大量的数据，这种就可以通过这个来判断它是什么行为导致的。比如过滤慢日志或者 SQL 洞察日志时，你就可以有一个方向性，比如你只需要确认的是哪类行为，其实可以去解析相应的 binlog ，去查看表结构，比如是否有主键能够快速地去确认这一类问题。

3.场景3：DAS自治服务-异常检测

现在介绍场景3 ：关于 CPU IOPS 活跃的一些突增，这种场景我们是经常遇到，无论是在自建数据库还是我们 RDS 很多客户经常提供这样的问题。

对于我们，很多时候在自建数据库，我们基本做监控会基于这种传统，会基于这种规则阈值的方式来监控，当达到比如某个阈值之后，我们收到告警再去核实处理，较好的可能会配置自动化的一些措施，如果收到告警，会自动地去 kill 超过多少时间的一些SQL。

在这里要给大家介绍我们 DAS 的功能，它可以继续学习，可以通过我们的 CPU IPS 活跃会话机监控指标，比如开通DAS，开通 SQL 洞察，它可以结合你的 SQL 洞察日志，还有一些慢日志以及你的锁情况来综合的去帮你做一个分析。它的准确性和时效性相对而言比传统的方式高很多，而且可以当我们检测到异常时，它是可以去做特征提取，根因分析。还可以做自动 SQL 优化， kill 异常 SQL 这样评优化，评估优化 SQL 效果的一个全闭环的链路。

大家有时可能会遇到很多场景，比如遇到很多客户他可能遇到 CPU 打满的时候，产生很多慢SQL，这时很多CPU 打满后，很多平常执行正常的 SQL 都被拖慢。此时慢日志里比如记录大量的Mysql，我们该如何方便快捷地定位原因？平常我们是否想，是否是通过记录 CPU 等指标高时的会话信息，方便赘述引起问题的 SQL ，如果从慢字句里面过滤，平常一般自建库是从慢字句里分析，可能效率比较低的过程。而我们 DAS 它有异常检测功能，比如 CPU 标高或者 IO 标高，活跃会话标高时，它可以帮你保存某个打高时间后某个时间点的一个会话，这样我们可以通过会话和结合它保留的慢字和 SQL 动画字，可以帮去分析你在这个时间段是哪一个或者哪一些 SQL，它的执行占比较高，或者它的执行时间比较长。我们就可以通过快速的比例或者排序就能够快速的定位相应引起问题的相应的 SQL。所以 DAS 异常检测一块功能，大家平常用于管理要经常使用，因为我发现很多客户没有用 DAS 的习惯。在这次培训中也是希望大家能够通过这次讲解，能够后续再遇到这一类问题，能够使用他。这就给大家展示我们在什么位置，等下我们通过做实验，可以看到在知识中心的异常事件里面，会有相应异常事件信息。

一般来说我们出现的私密波动，它主要总结是毛刺性，比如周期性的，趋势性的，还有均值偏移性的，还有新增的，无论是哪一种，我们都可以通过，如果它出现异常的情况下，我们都可以想到使用DAS 异常检测去查看。要注意一类是类似于 OM 的场景，它的内存可能执行一个 SQL 之后，它可能缓慢上升。之前也跟大家介绍就算开通 SQL 仲裁，但如果这条 SQL 引起 OM ，直接 Mysql 进程，它就直接故障，它很多时候是来不及记录相应的引起问题的 SQL 。此时我们要去追溯这样的场景，大家就可以去通过异常检测，查看当时他是否有异常事件，丢弃相应的会话快照。如果有，我们可以从会话快照里面查看当时都什么 SQL 在跑。重点关注一些执行时间比较长的 SQL。

这里给大家展示了具体的 DAS 异常检测的位置。在一键诊断，我们 RDS 技术进入 RDS 实例里，它左边列表有一键诊断，里面有知识中心异常事件。在异常事件里，我们可以选择在一个时间范围内的异常事件，就会展示出来时间段的异常事件信息。当然它也包含其他比如优化事件，弹性伸缩事件的一些事件，大家可以在这里面。

遇到这种，你可以点击详细。下方有异常快照，可以通过里面的信息查看。比如点进去后你可以看到它当时异常指标的一些信息，也可以显示异常指标，还是把实例的其他的一些指标都勾选，先展示出，在这里面也可以展示。

进入之后他也可以给你展示会话快照的信息。

像刚才给大家所讲，你可以关注在这个时间段哪些 SQL 执行比较多。比如查看它采集到的 SQL 执行量比较多的占比是多少，它的平均执行时强是多少？一般你可以在这排序，分别关注一下这两类的排序结果里面哪些 SQL 比较突出，你就需要重点关注这些 SQL 。在后面可以看到比如复制样本，复制样本它就可以打开后可以展示具体的 SQL 里一些样本的 SQL，优化可以帮你展示 SQL 的执行计划是怎样，能够快速地判断 SQL 是不是有问题的。限流可以把 SQL 加入限流 SQL 模板里，后期如果遇到这类SQL，比如当我们 CPU 打高至多少，就可以对 SQL 做一个相应的这种限流措施。

这下面的也会展示比如按照概要会话总数是多少，运行中的会话多少，运行中最长会话执行时间是多少。比如按用户访问哪一边，按数据库统计，给你展示。这里重点关注活跃会话。活跃会话，你可以点击后面的蓝色的字体，点击之后，比如这是734，它会把 734 个会话全部列出。你可以再用类似于排序的方式，比如线程状态排序的方式，你可以去查看哪些是正在执行一些命令，它的执行时长是多久，你都可以通过在这能够看得出。这就可以强调，大家可以去点击数字展开具体的会话信息的，这个地方它是可以记录到这个事物和锁快照的。如果出现源数据锁，它可以把源数据锁的信息给你展示出。如果这个事物持续时间超过 15 秒，它也可以把这个事物的信息给你记录。一些锁等待比如超过五秒，它也可以给你记录下来。

所以遇到这种锁类的问题，大家也可以通过模块去快速查看是否有问题。慢日志有慢日志统计和慢日志明细，它也是包含在异常时间段内的相应的信息，通过这种排序的方式快速地去找到相应的信息。比如这后面是有样本优化和限流，大家也可以点击。

这展示一个 CPU 突增的场景，大家可以看到它是把直接在这下面，比如你点击详细，它有根因分析和建议，异常快照过后如果你点异常快照，它下面的内容如下图所示。

如果你是看到它有明确的一些特征的，可能直接给你给出一个根因分析和建议。比如他会告诉你， SQL 存在问题，他的执行次数，平均执行时间，最大执行时间，这些他都会给你列举出，他会给你一个相应的优化建议，放在这下面，我们就可以通过给它优化建议，看是否找时间去执行相应的如 DDL 给它添加对应的索引去执行，再执行相应的signal，查看它的效率。

然后，我们要注意，不是每个场景我们都能够异常检测，都能给出根因分析的。当被异常诊断时，我们也可以通过配置一些优化和限流措施来做相应的动作。比如我们平常默认是仅 SQL 诊断，我们也可以通过比如 SQL 诊断并自动创建索引的方式。但是比如你是 CPU 正打高，它肯定不会这时去执行DDL，它是会需要在等你实例的运维时间段才去执行。所以这个时候添加索引，它并不是帮你解决当下问题。所以如果遇到 CPU 打高的情况，你需要勾 kill 异常SQL或者自己手动批量 kill 这些SQL，先快速恢复，后面再添加索引的动作。比如也可以去通过一些限流，比如指定 CPU 大于多少，活跃会话大于多少时，我们指定一个限流时间段，限流时间也是可以给它配置。当下次遇见时，我们就对这种特提取它的特征的 SQL 做一个相应的限流的措施。