记一次 TiDB Cloud Serverless 超额导致的博客超时故障

今天早上起来，习惯性地刷新博客统计页面，发现 502。这可不妙，好不容易我坚持到现在终于有点流量，于是赶紧想办法修复。

博客基础架构

我的博客架构大体是：

• 小主机，本地跑 php8.2-fpm 和 nginx
• 使用 nginx 代理提供服务
• 数据库使用 TiDB Cloud Serverless
• 外面套上腾讯云 CDN

仔细一看，错误页面的 Nginx 是 1.18.0，正是我服务器上的版本，貌似是本地上游 php-fpm 的问题，不是腾讯云 CDN 的问题。ssh 登录服务器，基本正常，验证了判断。查看错误日志，tail /var/log/nginx/blog-error.log，大量的 upstream 错误。top 查看进程负载，服务器本身很闲，但是 5 个 php-fpm 进程虽然不忙，但是都跑了很久。

重启治百病，先升级系统

以前没见过这种情况，本着遇事不决先重启的思路，我想先升级重启试试。于是 apt update & apt upgrade 升级系统，接着 reboot。停了一会儿打开网页还是不行。

登录服务器 service --status-all 查看服务，貌似都正常。查看博客服务器的配置文件，也没写错。输入 service nginx restart 和 service php8.2-fpm restart 重启服务，还是不行。

然后 Google PHP8.2、php-fpm、502 等关键词，限制最近一周，看看会不会是新版本引入了新 bug。没有找到结果，应该也不是。

会不会是 TiDB Cloud 没钱了？

看过前面博客：💪 WordPress 使用 TiDB Cloud 替换 MySQL 💪 的同学可能知道，我不久前把博客从本地 MySQL 迁移到了 TiDB Cloud Serverless。会不会是欠费停机了？我觉得不应该呀，免费额度 5GB，我的博客数据库前几天看过才区区 300+MB，不会突然就突破限制。

不过我还是打开了 TiDB Cloud，姑且看一眼吧。没成想，果然是 TiDB Cloud 额度用完了，不过不是容量问题，而是 RU（Request Units，请求单位，TiDB 的某个计费单位）超限。TiDB Serverless Tier 每个月有 50M 的免费 RU 额度，我当时已经用掉 59.6M，所以被停止服务了。

不过这里有个问题：我的 php-fpm 整个被卡死了，因为 TiDB Cloud 没有及时断开连接，导致我的 PHP 一直在等待数据库响应，但实际上数据库是不会响应的，相当于我的 PHP 线程都在守活寡。直到超时，才得到解脱。这样一来，我的服务器也无法响应任何其它 PHP 请求，包括 phpinfo() 等未使用 TiDB Cloud，甚至那些只有简单 PHP 功能的请求。

按理说我超额，他们应该拒绝连接，让我看到数据库连接失败的错误，而不是卡住我直到超时。这样一来，

1. 至少我的服务器还可以响应别的 PHP 请求
2. 有了数据库连接失败的错误提示，我也能尽快找到问题根源。

上调预算

TiDB 还是蛮大方的，不需要预付款、预充值，只要将来按用量结账即可。于是我把预算上调到 $5/月，然后，重启了服务器。结果，又发生了第二个意外。

我以为上调预算之后，连接、请求就能恢复，结果没有，还是白屏。而且，从 TiDB Cloud 的统计页面来看，在上调预算之后，数据库经历了一大波密集的请求：

直到约 30 分钟之后，我的博客才渐渐缓过来，我也才有机会写这篇复盘文章。

我不太确定这波请求是哪里产生的，是我的博客还是 TiDB 的网关，这个有待进一步研究学习。

请教 TiDB 大佬

我带着问题在推上请教了大 V 能哥。他告诉我，按照目前的产品策略，超额用户也可以以很低的频率访问数据库，因为有人是占了太多空间，需要有机会让他删数据。

那这就是彼之蜜糖，吾之砒霜了。我的情况是存储量少（不到400mB），但是请求数高（我看的时候为 60M），所以除非调高预算，我不存在继续使用的可能性。但是他们又不会拒绝我的服务，于是就变成了我服务器上的 php-fpm 被卡死在连接数据库阶段，无法响应任何 PHP 请求。

我把这个问题反馈给了 TiDB 的社区工作人员，期待他们能解决这个问题。

下一步：解决方案

这次故障的修复过程对我来说还是挺新鲜的，也还算顺利。给我在系统设计领域提供了新的经验，所以我拿出来分享给大家。

不过话说回来，从白嫖的角度来看，迁移到 TiDB Cloud Serverless Tier 上似乎不是很明智。按照 WordPress Jetpack 的统计，我现在每月访问量大约是 7k UV，10k PV，如果这个级别就要花钱，而且动辄几刀的话，那我可能还是迁回去用本地数据库好一些。

当然，解决方案还是有的。

首先，Serverless Tier 可以创建多个节点，每个账号的最初的 5 个节点都有 5GB 空间+50M RUs/M 的免费用量。所以我可以写一个自动化脚本，每周将数据同步到下一个节点，然后自动修改链接类到新的节点。嘿嘿嘿，不知道这样的作品能不能参加 Hackathon 😂😂

其次，好好查查 slow sql，找找优化点。减少每次请求产生的 RU 消耗。

再次，升级 CDN 配置。我目前的网页都是 30d 缓存，按理说不应该有很多消耗才对。后台只有我一个人在用，不应该有很多数据库访问。我怀疑还是这块儿没搞好。应该有不小的优化空间。

总结

TiDB 正在举办新一年的 Hackathon，我也厚着脸皮去要了 $100 的赞助，白嫖大业应该还能再坚持一段时间。如果你也对数据库应用开发感兴趣，我强烈推荐你也来参加这次 Hackathon：【TiDB Future App Hackathon 2023 】TiDB 首届全球黑客马拉松，开发者的狂欢夏日盛会！快来一起 Coding 吧！这次 Hackathon 针对应用层，基本上使用 TiDB Cloud Serverless 就可以，适合各个领域的开发者参加。

无论如何，感谢 TiDB 提供给我们免费、好用的数据库产品，也推荐大家使用 TiDB Cloud Serverless。如果大家有什么意见建议，欢迎留言讨论。