这是一个创建于 901 天前的主题，其中的信息可能已经有所发展或是发生改变。
描述下上周本小组经历的一次 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 的影响都非常小，不大可能是导出本身导致的问题
 |
1
rekulas OP |
 |
2
smallparking 2022-05-31 00:19:57 +08:00 via Android
说这个没有用 ，你那出查询计划出来 直接就一锤定音了
|
 |
3
IDAEngine 2022-05-31 09:21:58 +08:00
polardb 本来就是舍弃了很多 mysql 的功能特性换性能，有得必有失
|
 |
4
sss495088732 2022-05-31 09:47:48 +08:00
不知道为什么产品这么多问题还能继续卖.他们的 analyticDB,不能创建一个 GP 原生支持的 index 类型.
折腾了两个星期,然后说没办法了,然后跟我们说没有排期修改这个 bug. 腾讯云也是.容器镜像的服务上次在 V2 还回复我说改好了..真的在 V2 回帖还是跟同事确认清楚吧. 捆绑使用 coding,结果一堆 bug.创建完镜像触发构建的时候还能触发到别的容器上.拉取仓库代码还能拉到非指定仓库(一看就是前端 bug)真是绝了这些厂商 华为云更牛逼.那个客服工单跟没有一样.想起来了回复你一下.真实便宜没好货. 上云这些年并没有节省运维的成本. |
|
5
rekulas OP @sss495088732 有一些同感，多年的云服务经验告诉我，不出问题的时候确实比较省心，但一旦出了问题比自己维护更恼火，所以云服务到底节约了多少成本呢？这是一个量子力学问题 🤣
|
 |
6
TJT 2022-05-31 12:46:25 +08:00
曾经从 MySQL 迁移 PolarDb ，后来又换回来了，记得当时的原因是一次升级实例规格后出现了故障，而且长时间没办法恢复，连最基础的在线迁移升级都没做好，就不敢继续用下去了。
|
 |
7
encro 2022-05-31 13:59:30 +08:00
|
|
8
encro 2022-05-31 14:04:59 +08:00
polardb 一年不到 1 万能买什么配置？
你那个一秒读取 2000K 已经超出了。 |
|
9
sss495088732 2022-05-31 14:06:06 +08:00
@encro analyticDB postgresql 基于 greenplum,我要使用 GP 的特性(同个 version,选型的时候就是想使用这个特性),他没有,那使用上就跟上游的体验不一样了.
而且到现在他们还没找到那个特性为什么会导致数据库宕掉所以禁用掉了 最主要是他们并不准备解决... |
|
10
encro 2022-05-31 14:06:47 +08:00
数据量大，用户多的情况，新增字段必须用 online ddl 语法，修改字段必须等没人时候。
|
|
11
sss495088732 2022-05-31 14:12:11 +08:00
@rekulas 没有节省成本 0.0,呆过的公司使用云服务几年后都开始自建.尤其是云 GPU 服务器实在是太贵了.而且出问题没有正常服务器的支持工单售后
|
|
12
encro 2022-05-31 14:12:57 +08:00  1
|
|
13
encro 2022-05-31 14:15:36 +08:00
|
 |
14
gt15207 2022-05-31 15:07:38 +08:00
个人感觉：
一条 SQL 干躺一个大库(干掉 DBA 半年奖金)的例子见了太多了。 下次你可以在发生问题时收集 perf top （比如 perf top -s comm,pid,symbol ）输出， 看看消耗 CPU 的都是什么 OS,DB 函数， 你就知道是啥引起的问题了。 |
|
15
rekulas OP @encro 问题是总获取行数也才不到 300w 。。。，其实这个 db 的性能还是挺强的了，我们做活动并发几千还是能勉强抗住
|
|
16
encro 2022-05-31 15:29:41 +08:00
@rekulas
所以是 SQL 写得有问题？变成了 n * m 了。 show full processlist 和 慢查询日志能解决绝大部分问题。 看你内容，大家都有权限，所以你永远不知道一些数据库小白们用了什么神操作。 我曾经在一个大公司，发现勿删记录、线上改大表、慢查询飞起， 所以最靠谱的是数据库表设计和查询要交由专业人士来审核和上线。 |
|
17
encro 2022-05-31 15:34:43 +08:00
@rekulas
“其实这个 db 的性能还是挺强的了，我们做活动并发几千还是能勉强抗住” 不要强调这点，没有银弹， 当 Mysql 和 Pg 的工程师都是 SB ，没有阿里厉害，随便就能 N 倍性能？ 通常是某些地方耍小聪明投机取巧，如果具备普适性，那么会被社区合并到下个版本去，没有合并，那么可能不具备普适性。 |
|
18
sss495088732 2022-05-31 15:37:37 +08:00
@encro 诶.最离谱的是我照着他文档写的测试特性..现在那个文档还挂在上面呢...
|
|
19
rekulas OP @encro 正常导出而已，sql 都是固定的不会有问题 process 和慢日志都检查过了，结合异常报表，几乎可以肯定是服务的问题，只是不确定是硬件还是软件导致
|
|
20
encro 2022-05-31 15:45:41 +08:00
@sss495088732
估计遇到了问题没解决所以下掉? 主要负责工程师已经离职或者换岗，甚至项目线被砍掉都有可能。 不要太期待云计算公司开发的边缘项目会好过专业的数据库公司。 数据库设计的门槛还是挺高的，日志，自动化测试等都需要大量人力和物力支持。 如果这个他们内部在用，那么可能还好点，如果内部没用，那么估计就偶尔支持一下了，几个人走了一个就没法持续了。 |
|
21
sss495088732 2022-05-31 15:56:51 +08:00
@encro 上云还是得用主流的解决方案,少用他们的新产品...
TiDB 是永远的神 |
 |
22
orczhou 2022-05-31 20:30:16 +08:00 2
从性能趋势图来看，缓冲池的请求达到 200~300 万，是非常大的；另外，CPU 到 100%；扫描数据行数也有时候超过 150 万行 /秒，基本上是有比较慢的 SQL 或者批量大操作在持续执行。 找到这样的 query ，并优化之，是解决问题的根本原因。
真実はいつもひとつ！ 国内云数据库在诊断上普遍做得不太好，等待事件，Top SQL 如果有的话，应该很快可以破案。 本人前阿里云员工，对 PolarDB 还比较了解，现在已经无任何利益相关了。 |
|
23
rekulas OP @orczhou 见我写的案例和上面回复，并无任何异常 sql 或慢日志，如果那么简单我早就找到原因了，而且故障时间跟导出数据时间完全吻合，大概率是导出导致的问题并非问题 sql
|
|
24
orczhou 2022-06-01 09:50:00 +08:00
11 点 10 分~12 点 10 分之间，持续了一个小时的内存池每秒读取超 200 万，行扫描 /每秒超 100 万，说明是有“操作”在执行的；“重启之后只正常了 10 秒左右 2 个节点瞬间又拉到 100%”说明这个“操作”并没有重启而停止，而且从性能指标来看，这个“操作”应该持续了 1 个小时
|
|
25
rekulas OP @orczhou 我再次检查了慢日志，有发现异常如图
https://imgur.com/a/20iOBZz 确实发现了异常所在，慢日志大幅增加而且有几条扫描行数很多完全有可能导致 1 小时的异常扫描。 但是如果事情这么简单就好了，如下图这是我们平时其他时段搞活动的慢日志记录 https://imgur.com/BH82HF8 可以看到差异巨大，也就是慢日志增加是果而不是因，而且这里还有个无法解释的 bug：我们在 1 小时内的那个大扫描行 sql 请求远远低于慢日志中的数量，我对比了两者的 QPS 、MPS 都在一个水平上，没有理由 24 号的扫描行数差异如此巨大-我对比了 1 小时的总扫描行数，大概在 10 倍差距左右 |
|
26
orczhou 2022-06-02 14:11:25 +08:00
目前，从看到信息来判断，是无法得出什么结论的，只能做一些猜测，再去验证。
通常的，对于 MySQL 数据库，在系统异常的时候，MySQL 慢查询数量的经常都会增长，如上所说，经常都是果不是因，因为 MySQL 并不记录这条 SQL 是为什么慢，是排队还是锁，还是执行时间长。另外，因可能也隐藏在这个大量的慢 SQL 中，只是通常比较难以排查。 目前的信息，还比较难看出是哪里的问题。可以考虑从应用的角度也去排查，看看出现了哪些不应该出现的 query ，或者以前执行次数很少的 query ，现在变多了。如果整体应用系统波动都不大，那可能就是 PolarDB 或者阿里云有什么不稳定的地方 |
 |
27
czz19891012 2022-06-02 16:26:29 +08:00
阿里云这边的工程师, 因为实例已经销毁了不好确认, 其实我们内部有一个叫扁鹊的系统, 这里 cpu 已经 100% 了, 我们通过这个系统可以看到当时的 cpu perf 信息, 就可以确定原因在哪里了...
|
|
28
rekulas OP @czz19891012 实例其实一直在跑着的还没销毁 pc-2vcj6a9ih099bjpgm
|
|
29
czz19891012 2022-06-09 00:39:51 +08:00
嗯.. 我搞错了 你这个是成都可用区, 不是公有云可用区. 我查错了, 确实还在
我们这里监控只有最近 7 天的数据, 我看最近这 7 天是正常的.. 我看监控里面 cpu 已经跑了 100% 了, 这个其实在 DDL 的时候 2c 的实例跑 100% 很正常的, 因为后台还有物理复制, 统计信息更新, IO 等等一系列的线程的.. 后续有问题你可以知乎或者微信钉我 |
|
30
czz19891012 2022-06-09 01:22:17 +08:00
@czz19891012 @rekulas 又看了一下, 在慢日志里面看到你这边有很多在 5.24 日 11 点左右的慢查询, 这些慢查询都扫描 100w+ 的行, 这些 sql 你可以关注一下
|
|
31
rekulas OP @czz19891012 ok
不过正常情况下我们 cpu 一直低于 20%，扫描多的 sql 一直都在，但从不会进入慢日志级别，直到我们上次导出数据的时候。。。而且也不涉及到 ddl ，其实最好调查的时机是故障时直接登录服务器查看异常进程和 sql ，可惜那时候联系不上技术只有漫不经心的工单在回复 |
Select Language
