前言
前不久在实习的时候搞了个P1故障,导致服务不可用将近一小时,最后排查复盘发现竟然只是一个二级索引!
一、业务背景
5000w+数据,1024分表
中午12点准时推单,一般推单会持续15min-30min,该业务为核心业务,一旦受阻影响面很大。
二、故障出现
业务侧反馈中午推单卡住,一单未推(该业务为关键业务,很紧急,影响面大)。
上阿里云日志看到
Error updating database.
Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: [15b848918060c000-2][10.0.62.142:3306][booking_center]ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL]
Error occurs when execute on GROUP 'BOOKING_CENTER_1617764186004XHSA_PURM_0001' ATOM 'rm-bp17rbdzegw1600mp_booking_center_nmqq_0001': Lock wait timeout exceeded; try restarting transaction
报警出现大量锁等待超时。
同时钉钉群里有大量长事务告警。
三、故障定位&&止血
12:19 初步定位
看到报警内容,可以定位到是数据库长事务导致新的语句无法执行。此时确定是数据库的问题,开始联系dba解决。
由于是饭点,其他开发和dba都去吃午饭了,都匆匆赶回公司。
12:38 dba到场
看到故障的第一反应是kill掉所有的长事务,但是尝试kill发现并不能成功kill。
回顾最近的修改,只有昨天五点左右删除了相关表的一个二级索引。我们推测和这个有关,所以建议执行增加二级索引的DDL操作。
12:43 执行后发现该索引一直在pending,没有执行,猜测是长事务霸占了行锁。开始联系阿里云技术人员支持。
此时所有update都被阻塞。
我们找到了产生长事务的sql
<!-- 经过脱敏的代码 -->
<update id="***">
<foreach collection="***" item="i" open="" close="" index="index" separator=";">
update bh_order_line
<set>
<if test="i.a!=null">
a=#{i.a},
</if>
<if test="i.b!=null">
b=#{i.replaceProductInfo,typeHandler=...},
</if>
<if test="i.c!=null">
c=#{i.c}
</if>
</set>
where id =#{i.id}
</foreach>
</update>
这时开始分析,意识到该sql用了id进行定位,而分区键是order_id。在没有二级索引的情况下,每一条update都会下发请求到所有分表,而该事务有多个update(几十个),从而导致长事务的发生,而之前推单为了快速完成,所以这个量是非常大的,进而导致拖垮整个库。
这时基本确认是二级索引删了的缘故。
此时也考虑了其他方案,比如改代码,增加查询条件,从而命中分区键,但发现代码没有做防腐层,改起来很难,复杂度高,在没有测试的情况下容易出大问题,于是否定了这个方案。
12:50 阿里云技术人员定位并给出了kill语句尝试kill,执行没效果。
在kill不掉长事务的情况下,打算重启,但阿里云并没有针对单个私有rds重启的按钮,只能重启整个drds。而该drds上涉及很多其他的业务,影响面太大了。
考虑到该故障极大可能短时间内无法有效恢复,开始考虑人工止损,由于查询导出走的是订单中心(ES),所以导出功能正常,此时由文员人工导出并审单分配。
13:00 阿里云技术人员决定重启cn节点,此时评估影响,阿里云技术人员说明可能会出现闪断,大约 3min 左右。
考虑到重启是为了停止所有长事务,让增加索引的操作顺利执行,而此时服务还在源源不断发送update产生新的长事务。所以此时需要先关闭服务。
13:04 等待业务方完成导出后关闭(因为需要人工推单来兜底止损)
13:31 停掉我们的服务,重启drds
增加二级索引的DDL操作开始执行,发现进展缓慢,预计要1-2小时。
13:58 我们觉得实在太慢了,询问有没有加速的方法,阿里云技术人员提供了新的方法,并由他们来操作,发现速度快了很多。(改了参数)
14:24 二级索引添加成功,重启我们自己的服务,服务恢复正常
四、事后复盘
删除二级索引的动机
当初删除二级索引是为了避免触发阿里云一个已知的bug
二级索引的设计
原先二级索引的设计确实是有问题的
这也是为什么当时阿里云技术人员都认为该索引是无用的。
如果要选择gsi二级索引去优化 用id查询无法命中分区键的问题,那么正确的建立gsi语句应该是
GLOBAL INDEX `idx_gsi_id`(`id`) COVERING (`order_id`) DBPARTITION BY HASH(`id`)
至于为什么原先那个二级索引能起到部分作用,原因在于,虽然之前的二级索引也是全表扫描,但是扫描的表不同,它扫描的是索引表,索引表只有8个,而对于主库的表有1024个,扫描索引表花费的时间更少,即使还要回表,但此次回表并不需要去下发请求到每个主表当中。
不过根本原因还是评估不到位,并没有考虑到二级索引删除可能带来的影响。
五、故障总结
开发侧:
1.历史背景设计不合理性与阿里云版本的bug导致
因 bh_order_line 表中GSI索引 都需要根据 查询字段id ->与order_Id 做一层映射关系,不然无法找到order_Id 对应的分库,
就会全局查询,出现异常告警或长事务慢SQL,如果GSI索引有映射关系,但是所有查询都要查询二级索引表然后回主表查询,会出现之前告警出现的异常
合理设计
GSI索引 建id->与表中热点key建立(除去order_Id)这个字段,代码SQL查询时候带上分库主键order_Id进行查询
2.代码层是否健壮(能否做到熔断,降级,快速修改代码进行止血等能力)
DBA侧:
1.线上删索引操作应该落实工单审批流程。
2.drds1.0库,增加应对突发的数据库请求流量、资源消耗过高的语句,进行限流熔断的机制;
阿里云:
1.线上当前版本bug触发业务偶发报错,同时gsi索引存在回表也会触发bug;
2.线上当前版本bug,导致kill 'all’操作不起作用,升级版本后才能解决;
3.ddl加了限速,导致ddl操作十分漫长,影响恢复进度;
结语
作为实习生第一次搞出这么大的故障,还是蛮惭愧的,而原因竟然只是因为一个二级索引!
还好有DBA、Leader和mentor的支援,不然就我一个肯定GG。
第一次经历故障的止血和恢复,说实话学到了很多很多,在复盘阶段,也学了很多sql优化的相关知识,团队也开始着手处理之前一直出现的慢SQL问题。
多亏了Leader和mentor,不然没有线上处理故障经验的我直接GG。
这次故障也为我敲响警钟,对待问题需要小心再小心,尤其是线上问题,对待线上,要有敬畏之心!
同时自身也要去深入学习自己使用到技术和工具,只有掌握底层原理,才能在做技术方案时更加全面的考虑到各种情况的可能。
文章评论