三招搞掛Mysql(轉)

標籤：

一、產生大量的undo日誌

眾所周知，InnoDB是一個支援MVCC的儲存引擎，為了支援MVCC，InnoDB需要儲存undo日誌，以便對使用者提供記錄的曆史版本。如果我們開啟一個事務，反覆地更新一條記錄而不提交，會怎麼樣呢？將會產生大量的undo日誌，使得磁碟空間爆滿，導致MySQL不可用。

在innodb現有的實現中，並沒有對單個使用者或單個串連使用的undo空間進行限制。也就是說，我們只需要反覆更新一條記錄，而不提交，就會產生大量undo日誌。由於我們的事務沒有提交，undo日誌不能被回收，從而使得磁碟空間被耗盡，最終導致MySQL掛掉。

Jeremy Cole老早就提到過這個問題，不過該問題至今還存在。要進行該項測試，只需要有更新記錄的許可權即可。測試指令碼如下：

測試過程中，可以觀察磁碟空間的使用率，一直在上升：

磁碟空間滿以後，再執行SQL語句就報錯了，錯誤資訊如下：

錯誤記錄檔如下：

可以看到，雖然MySQL進程還存在，其實服務已經不可用了。事務在執行過程中，會產生undo日誌以及binlog日誌，佔用磁碟空間，如果我們線上上執行一個大事務，就需要留意是否有可能因為undo和binlog導致磁碟空間爆滿的情況。為了規避風險，我們還是應該儘可能地避免特別大的事務。

二、定義大量的變數

上面的例子並沒有真的讓MySQL進程掛掉，而且需要對資料庫具有寫的許可權。你可能不服，那麼，我們再來看另外一種情況，即定義大量的使用者變數。

這種方式將會導致MySQL佔用的記憶體急劇上漲，最後被作業系統kill掉。而且，不再需要有更新記錄的許可權，只需要有登入資料庫的許可權即可。

測試指令碼如下：

我們不斷地定義使用者變數，可以通過pidstat觀察MySQL佔用的記憶體：

可以看到，MySQL佔用的記憶體越來越大，最後，MySQL進程不在了。通過dmesg可以看到，是由於MySQL佔用記憶體太多，被作業系統kill掉：

上面的例子示範了一個普通使用者耗盡資源，導致MySQL被作業系統kill掉的情況。其實，這個問題是完全可以避免的。MySQL支援在建立使用者的時候，限制使用者使用的資源。

可以限制的資源套件括：

• 每小時的查詢次數

• 每小時的更新次數

• 每小時的串連次數

• 同時建立的串連數

使用方式如下所示：

雖然MySQL支援限制使用者使用的資源，但是，在實際使用過程中，很少有人會去限制使用者使用的資源，甚至很多使用者根本不知道MySQL提供了這樣的功能，這給”不法分子”有了可乘之機。

三、觸發MySQL的bug

可以說，寫MySQL的都是一群科學家，並且，MySQL使用如此廣泛，遇到MySQL的bug應該不容易。不過，只要是程式就有可能存在bug，所以，遇到MySQL的bug也不是不可能的情況。如果看MySQL的release note，每次的新版本都會修複無數的bug。尤其以新功能的bug居多。

這一節，我們來測試一下MySQL的bug。即在使用grant授權時，如果使用了一個很長的資料庫名，將導致MySQL掛掉。之所以選擇這個bug，是因為該bug複現起來特別容易了，只需要執行一條SQL語句即可。

如下所示：

很明顯，該問題是由於緩衝區溢位導致，這也是我們編程中容易犯的一個錯誤。這個bug在MySQL 5.7中已經修複，我在5.6.19中進行測試，MySQL立馬掛掉，可以說是搞掛MySQL的最快方式。

四、總結

在本文中，我示範了三種搞掛MySQL的方式，這三種方式的思路不同，涉及到的知識點也不一樣。將這三種方式都嘗試一遍，可以搞掛正在使用的無數MySQL執行個體。那麼，是不是說MySQL特別脆弱，非常容易被搞掛呢？答案是否定的。MySQL在各互連網公司廣泛使用，已經經受住了無數的考驗。

本文之所以顯得MySQL容易被搞掛，主要還是因為大部分人的使用姿勢不當，以及對MySQL的瞭解不足所導致的。要避免MySQL掛掉，這裡有幾點建議：

• 特別大的事務會佔用特別多的資源，甚至出現佔滿磁碟空間的情況，要避免特別大的事務；

• 限制使用者使用的資源，避免不良使用者惡意破壞；

• 緊隨社區的腳步，關注社區報告和修複的bug，必要時升級資料庫版本，以免遇到已知bug；

• 新功能一般bug較多，不要上得太快，避免踩到未知bug。

三招搞掛Mysql(轉)