前言: 在廣州這座城市下著小雨的晚上，我正在廚房洗著碗，突然手機有來電，脫下手套，一看是來自阿里云的告警電話。打開飛書查看告警內(nèi)容，發(fā)現(xiàn)某個業(yè)務的RDS只讀實例CPU飚到100%，下意識覺得是不是有慢查詢導致，想著不會有啥問題，上去kill慢查就好了，結(jié)果發(fā)現(xiàn)是大問題....
一、發(fā)現(xiàn)問題
? 2024年3月10號 21:22分左右，手機響起來自阿里云的告警通知，確定了是阿里云RDS報警,MySQL有一波連接數(shù)進來，數(shù)據(jù)庫CPU瞬間100%，MySQL連接數(shù)也觸發(fā)告警，10分鐘不到有35000多條慢日志，同時阿里云只讀庫進行了實例主備切換（故障切換）
問題影響了線上用戶登錄和充值，當時工作群運營反饋問題，技術(shù)這邊也關(guān)注起來。
二、分析造成原因
業(yè)務運行的RDS是1主4只讀的架構(gòu)，然后開啟數(shù)據(jù)庫代理，讀寫分離。
一開始以為是管理后臺有人在查數(shù)據(jù)，全表掃描或者查看日期時間范圍很長導致只讀庫有慢查，因為之前出現(xiàn)過這種情況，結(jié)果看到控制臺幾萬條慢查詢。影響我判斷的告警來了，只讀實例出現(xiàn)故障進行主備切換，以為是實例出現(xiàn)問題，我立馬去找阿里云客服問實例是否有問題，為什么會主備切換了。結(jié)果技術(shù)客服回答，是因為有一波連接數(shù)進來，慢查里面執(zhí)行SQL有掃描行數(shù)很大的可以看看。然后就發(fā)現(xiàn)了下面這個關(guān)鍵語句,執(zhí)行1127次，每次掃描3789828行導致CPU漲到100%，
SELECT *
FROM `table_info`
WHERE user_name = ' '
AND game_xxxx = '123abc'
AND platform = 'xxxpay'
LIMIT 1
于是立馬反饋給該業(yè)務的開發(fā)，復制粘貼到群里，開發(fā)說user_name是空的，開發(fā)也很快修改代碼發(fā)布到線上，本以為就要結(jié)束了，結(jié)果還是有這樣的SQL進來，這就神奇了....然后懷疑user_name不是空的，會不會是空格，結(jié)果我復制出來到文本編輯器，因為開了符號顯示，發(fā)現(xiàn)user_name的值是空+空格，真想大白了，太可惡了。
?三、解決辦法
開發(fā)同事修改代碼，正則匹配過濾，業(yè)務恢復
四、個人反思
1、遇到類似問題，細心按照流程思路找問題，不要急 2、第一時間先把阿里云告警臨時關(guān)閉，不然一直打電話影響排錯 3、查看告警的只讀活躍會話，如果有執(zhí)行特別長時間的SQL，立馬kill別影響業(yè)務。 4、如果慢查特別多，先對掃描行字段進行排序，找出掃描行特別多的SQL再分析 5、事后總結(jié)，做好記錄，處理事故同時也得到積累和進步
文章來源：http://www.zghlxwxcb.cn/news/detail-841347.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-841347.html
到了這里，關(guān)于記錄惡意SQL注入引發(fā)的RDS只讀數(shù)據(jù)庫CPU飚100%的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
