Mysql插入2.6億條垃圾數據後會發生什麼?

問題現象

今天下午業務人員發現某功能無響應(該功能一天前上線)，技術人員初步診斷後發現是某個DB不太正常，DB爲Mysql 5.7.18。

登錄DB服務器後，進行檢測後發現了以下問題：

innodb_trx中發現異常事務

2個事務狀態爲 inserting ，數據量約爲 2.65億，事務開始時間爲昨晚23點

• dw_repayment_monitor空間擴展到73G

事務操做的表佔用空間急劇擴大

binlog佔滿了日誌盤

binlog設置的過時時間爲10天，文件分片大小爲100M。/var/log/mysql下產生了大量的binlog，寫滿了服務器上的一塊日誌磁盤

CPU/內存耗盡

top命令後發現CPU全被 mysqld 佔用

23G內存所有是buff/cache，內存所有耗盡

解決過程

stop問題應用

首先，緊急stop了問題應用，避免問題升級。

kill 事務對應的mysql thread

kill掉 trx_mysql_thread_id中對應的mysql thread， kill以後，show processlist 已經沒法查到這兩個thread.

兩個事務開始進行rollback

轉移binlog

將這些天的binlog轉移到其餘磁盤，確保mysql binlog可以繼續寫入

嘗試處理兩個rollback事務

嘗試處理掉兩個事務，各類折騰以後，宣告失敗。

• 與技術&業務溝通後，知曉該表數據能夠自動重建。所以以root用戶打算直接刪除該表，可是失敗

Table is locked by the server

• 發現 innodb_force_recovery,可是不敢亂用
• 發現rollback速度爲每秒約1W條，2.6億數據。回滾須要約7個小時，此時是下午三點多

上報風險

因爲本身沒有這種狀況的處理經驗，目前已經沒法進一步處理，所以上報至了CTO，避免進一步產生風險。

簡要描述狀況，CTO初步檢測後，給出A/B方案：

• A：先等待正常回滾

• B：若是沒法回滾完，考慮中止Mysql. 使用備份數據啓用備庫

最終結果

因爲時間還來得及，採用了A方案，等待DB天然回滾。接下來就是不斷檢測事務rollback狀況，2個rollback事務歷經5個小時，到晚上9點終於回滾結束。在此期間，其餘同事找到了相應的程序BUG，一個存儲過程當中的死循環自昨晚23點開始瘋狂往表中插入數據。

因爲這張表目前達到73G，所以刪除再重建了此表，利用程序進行數據恢復。

總結

平時雖然能處理些Mysql常見問題，但不少極端狀況仍是沒法處理。一方面是Mysql技能深度不夠，另外一方面也是經驗的缺失。本文僅記錄本次過程，同時也積累了些mysql待學習知識點，其餘思考再也不撰寫。