记录恶意SQL注入引发的RDS只读数据库CPU飚100%
前言: 在广州这座城市下着小雨的晚上,我正在厨房洗着碗,突然手机有来电,脱下手套,一看是来自阿里云的告警电话。打开飞书查看告警内容,发现某个业务的RDS只读实例CPU飚到100%,下意识觉得是不是有慢查询导致,想着不会有啥问题,上去kill慢查就好了,结果发现是大问题....
一、发现问题
2024年3月10号 21:22分左右,手机响起来自阿里云的告警通知,确定了是阿里云RDS报警,MySQL有一波连接数进来,数据库CPU瞬间100%,MySQL连接数也触发告警,10分钟不到有35000多条慢日志,同时阿里云只读库进行了实例主备切换(故障切换)
问题影响了线上用户登录和充值,当时工作群运营反馈问题,技术这边也关注起来。
二、分析造成原因
业务运行的RDS是1主4只读的架构,然后开启数据库代理,读写分离。
一开始以为是管理后台有人在查数据,全表扫描或者查看日期时间范围很长导致只读库有慢查,因为之前出现过这种情况,结果看到控制台几万条慢查询。影响我判断的告警来了,只读实例出现故障进行主备切换,以为是实例出现问题,我立马去找阿里云客服问实例是否有问题,为什么会主备切换了。结果技术客服回答,是因为有一波连接数进来,慢查里面执行SQL有扫描行数很大的可以看看。然后就发现了下面这个关键语句,执行1127次,每次扫描3789828行导致CPU涨到100%,
SELECT * FROM `table_info` WHERE user_name = ' ' AND game_xxxx = '123abc' AND platform = 'xxxpay' LIMIT 1
于是立马反馈给该业务的开发,复制粘贴到群里,开发说user_name是空的,开发也很快修改代码发布到线上,本以为就要结束了,结果还是有这样的SQL进来,这就神奇了....然后怀疑user_name不是空的,会不会是空格,结果我复制出来到文本编辑器,因为开了符号显示,发现user_name的值是空+空格,真想大白了,太可恶了。
三、解决办法
开发同事修改代码,正则匹配过滤,业务恢复
四、个人反思
1、遇到类似问题,细心按照流程思路找问题,不要急 2、第一时间先把阿里云告警临时关闭,不然一直打电话影响排错 3、查看告警的只读活跃会话,如果有执行特别长时间的SQL,立马kill别影响业务。 4、如果慢查特别多,先对扫描行字段进行排序,找出扫描行特别多的SQL再分析 5、事后总结,做好记录,处理事故同时也得到积累和进步