不吐不快，一次意外宕机事故，让我对阿里云 polardb 充满了疑惑

描述下上周本小组经历的一次 polardb 数据库宕机事故，为了尽可能公正已经尽量屏蔽个人主观思想。

polardb是阿里云目前主推的商业数据库之一，完全兼容 mysql 且具有极好的性能，官方宣传比 mysql 快几倍(我们使用中也感觉是要快些至于倍率没测试过)，在市场上知名度很高。

背景：我们从 2020 年开始使用 polardb ，一直以来表现良好。

团队有内网业务+外网业务，因此内外网均有数据库部署，内网是自建 mysql8 ，外网是 polardb 基础版本 2 核 8G*2 节点，基础年费大约 6k 再加一些额外费用大概 7-9k/年。

事故描述：

24 日 11 点突然收到 polardb 数据库异常告警邮件，随后同事告诉我进行了数据库导出导致数据库似乎无法访问了，我立即开始处理。 ps: 其实在 16 号我们也经历过一次事故，同事在早上执行了一个 alter table 命令，随后发现所有数据库均无法访问，我发工单联系后才找到重启按钮进行重启随后恢复，也理解这次事故毕竟高峰期执行 DDL 类操作本身就有一定风险，但我心中仍然埋下了一些不满：我们内网数据库即使高峰期执行 alter 操作也最多影响关联的几张表，不至于影响整个服务器（所以当时我怀疑数据库隔离没做好）。问题解决之后提醒过同事尽量避免白天执行表结构操作。

而这次同事通过 navicat 拉取几张表时，突然中断异常并导致数据库卡死，很多服务访问极其缓慢，查看 cpu 发现一直 100%不降，我立即登录 navicat 查询 processlist ，但是没有发现任何异常，这时候我心里还比较轻松，毕竟 polardb 重启一次还是比较快的，所以果断点了重启以为马上就恢复了。

然而随后发生的事情让我陷入了迷茫，重启之后只正常了 10 秒左右 2 个节点瞬间又拉到 100%，我再次检查 processlist 和事务表，仍然没有发现异常进程或 sql ，就有点慌了，立即电话阿里云客服以为这样可以快速得到技术支持，然而浪费了几分钟时间客服让我提工单会有专人处理，虽然我已经严重声明发生了重大事故。。。

没办法我只能发起工单，过程并不愉快，因为我描述了发生重大问题请立即协助，阿里云仍然半小时后才发来一个：已收到您的问题，我当时就有点发火了，言辞激烈请对方立即安排专人帮忙协助查询异常原因，但对方仍然不紧不慢的回复，一会说慢日志导致一会说 io 访问量太大导致。

我这时也对阿里云协助失去了信心，只能采用最后一个办法-临时升级配置，为什么一开始不升级，因为我不敢赌：阿里云升级和开通新服务时间不稳定，有时候几分钟完成有时候要半个小时，在部分服务还能勉强使用的情况下贸然升级有可能导致更严重的问题。

幸运的是这次事故运气比较好，10 分钟左右就完成了，随后我也发现 cpu 开始回复正常，所有数据库也恢复正常。

后续：我本想让阿里云下来再继续协助调查为什么 cpu 异常，但是工单客服一直像机器人一般回复，我也失去了兴趣，只是今年打算 polar 到期之后迁移倒 ecs 上，毕竟 ecs 还是比较稳定，之前看重 polardb 主要就是看中稳定性，但是如果稳定性得不到保障那还不如放到自建，我们自建数据库也连续 4 年未发生过重大异常，还是挺稳定的，唯一要担心的就是热备份问题。

附件截图：阿里的回复
https://wx2.sinaimg.cn/mw2000/786620bcly1h2qtesa7akj21e01jkdog.jpg
cpu 、innodb 缓冲请求、IO 吞吐量
https://wx4.sinaimg.cn/mw2000/786620bcly1h2qtes0jrlj20xc0xctby.jpg
iops 、扫描行数、tps
https://wx1.sinaimg.cn/mw2000/786620bcly1h2qtes4zdij20xc0xcn0w.jpg

事故分析：事故结束后我仔细查看了日志报表，首先确认了客服说的 io 和慢日志都不是事故主因，从报表中可以看到 io 和 iops 都不高，不可能卡死整个实例（也检查过带宽也很低），异常的数据有 innodb 缓冲请求和扫描行数，因为同事导出的总数据量才大概 2-3 百万级别，这个扫描量显得极其可疑，我在事故后也重新复制了一台新实例模拟事故场景，都没有发现 cpu 、io 、scan 有不正常波动，因此我有点怀疑 polardb 本身 bug 导致或者实例所在机器有缺陷导致。

其实整个事故我最不爽的并非事故本身，而是阿里云的处理态度，在发生严重事故了没有协助客户积极处理，第一个回复花了半个小时，之后的回复也在水，我感受不到对方有一丝急迫的心情，事故完成后也不愿去调查事故原因只会顾左言他，这才是我决定放弃 polardb 的主因。如果他们愿意认真调查下，在事故持续的大半个小时里进入实例服务器检查异常，我也绝对会积极配合跟他们一起找出问题来，然而并没有。

疑惑点 其实第一次的 alter 事故我还是有些疑惑的，因为一个访问量并不大的表更新卡住了整个实例的所有数据库，这正常吗？我们有几台自建数据库也只有 2-4 核但是执行 ddl 操作也最多卡住部分表而已。

第二个疑惑点就是 navicat 导出怎么可能导致 cpu 资源耗尽，我们事后认真检查了确认 navicat 导出只有 select 和 show 命令，正常来说这是比较安全的，而且我们随后测试对 cpu 和 io 的影响都非常小，不大可能是导出本身导致的问题