大型商用平台线上数据库故障恢复纪实

大型商用平台线上数据库故障恢复纪实

一切要从2023-12-13早上说起。

每周的1、3、5早上09:15，是我带的项目固定开晨会的时间。从2021年到现在，只取消过两次，一次是阿根廷夺得世界杯次日的早上，一次是v3.4版本发布，攻关解决harbor问题到凌晨03:30，早上太多人缺席，没有开晨会。

12-13早上，照例开完晨会，用户从各种渠道反馈，现网的报表查询功能严重卡顿，查询结果半个小时都无法生成。运维同事反馈，存储报表数据的clickhouse的数据库连接冲到了400个以上，内存也在飙升。临近年底考核，用户需要查询报表分析他们的经营数据，服务出现长时间异常很容易引起客户的不满情绪。

开发同事分析发现，查询clickhouse数据库卡顿主要是三个慢查询语句造成的，这三个语句已经执行了将近1个小时。按照之前的经验，只要这三条报表查询语句顺利执行完，数据库性能将快速恢复。但是，现在不是平常，是年底考核的关键时期，用户对服务异常的忍耐程度是不一样的。

谈到服务稳定性，通常是4个9或者6个9这种指标，达到4个9一年服务不可用的时间不能超过若干分钟等等。现实情况，在不同时期，用户对服务稳定性的要求是不一样的，甚至差别很大。数年前在一家通信公司，公司的产品支撑欧洲某国客户4G通信，承诺的一年服务不可用时间不超过24小时。该产品研发过程质量要求很高，发布后也很稳定，但是偏偏2012年欧洲杯决赛那天业务出现了若干小时的中断，虽然最终全年的服务不可用时间达标了，但是热爱足球的欧洲客户还是表达了强烈的不满情绪，给公司名誉造成了不好的影响。

所以，这次的服务卡顿问题要快速解决，不能再等！

既然服务卡顿的原因很清楚，是那三条慢查询导致的服务雪崩，那么解决问题的策略很简单：“停止这三条慢查询，让其他请求得到响应”。

如何停止这三条慢查询？

使用clickhouse的命令，kill掉正在执行的语句，不起作用。

运维同事给了一条命令，可以看到当前clickhouse正在执行的查询进程。在数据库表里查看，pid也能对应上。这时候已经是上午10:30了，负责运营的同事已经快顶不住用户的轮番轰炸了，这种压力也传递到了运维和研发团队。