RDS故障分析，请阿里云给予解释

1. 事件经过描述
2016年5月27日7时许，研发人员接到前方反映两家用户的系统运行有问题——用户正常登录后，画面操作没反映。
初步怀疑是应用系统故障，但后来发现主数据库实例有报警，并且多家系统运行缓慢。据此，基本确认RDS实例存在问题。
研发人员按如下方式进行了处理。
第一次：8：30左右对RDS实例进行了重启。但重启后故障仍未消失。
第二次：停止全部Tomcat应用，之后分步有序重启。但故障现象仍重复。
第三次：停止全部Tomcat应用，于9:00左右，再次重启RDS实例。只启动少数几家（五六家）的Tomcat应用。但故障仍未解决。
经过上述处理，在仍无法解决故障的情况在，决定对RDS实例上的数据库进行迁移，并逐步恢复迁移出的应用。
至17:00左右，共从原RDS实例上迁移出22家应用的数据库到新购买的2个RDS实例上，全部Tomcat应用恢复运行完毕。


2.故障原因分析
本次宕机事故，可初步判定由原RDS实例故障引起。判断依据如下：
1.反复重启后，并且在只启动少数应用的情况下，故障仍未恢复。
2.数据库在02：00至11:00左右的异常表现。

2.1    数据库连接数异常

从上述两图中可以看出，在02：00时左右，连接数突然变为零。并从零开始出现一个明显的波峰。该波峰在图“最近7日情况”中极其明显。日常应用基本保存持在200左右，但从02:00至09:00之前，数据库连接持继保持在600左右。
2.2    数据库缓存异常




从上述几张图中可以发现：
1.2016年5月27日前，数据库缓存情况正常。
2.从2016年5月27日02:00开始，缓存出现异常。
分析与此同时间段的缓存申请情况，与其它时间段并无异常。


2.3    IOPS及磁盘空间异常增高
  

从“7日IOPS情况”图中分析，至2016年5月27日前,IOPS基本正常，维持在一个水平线上。但从5月27日02:00开始，IOPS出现一个异常明显突起。

通过查阅报警信息，在02:29:46秒时，第一次出table full信息，持续到08:50左右。


分析磁盘空间情况，在同时出现IOPS升高与table full报警的同时，磁盘空间使用量突然增高。

2.4 与异常现象相伴随的正常现象
2.4.1 临时表无异常

图中临时表数量在11:00-16:00出现增多，但此时数据库未报table full之类的异常。此时，研发人员正在做数据导出迁移工作。在出现异常的主要时间段内(二时至八时)并未发现异常增量。

2.4.2 网络流量正常

12:00左右的波峰出现与大量数据导出相符合。异常时间段内的网络情况与其它日期内的并无明显区别。

2.4.3 数据操作量正常

分析上图，可以认为在故障时间段内，数据的查询与插入操作量无明显增加。无论如何，以故障时间段内，数据的操作并不是最多的。
3.    故障发生前的可疑情况

故障发生前的2016年5月26日 20：30左右。研发人员发现如上图未曾见过的情况：故障RDS实例正在升降级中。  咨询阿里，说是对RDS进行维护。


3. 分析结论
2016年5月27日发生的宕机事件，应是由RDS实例异常引起。综合上述分析，很有可能是由于磁盘空间胀死导致。
在异常时间段内，通过分析数据操作、临时表及网络流量情况，应与应用无关。
同时，最值得关注的时间点是02:00。在这个时间点有如下二点值得关注：
1.数据库连接数突然变为零。(应用是不可能的，有druid连接池，有30s/sec的服务请求)
2.缓存突然出现异常，MyISAM KeyBuffer出现断崖式下降。
上述分析，仅基于可获取的公开数据。具体RDS实例故障的深层次原因，请阿里云坦诚布公，给出更有深度的分析报告!