《如何三招搞掛MySQL?》要點:
本文介紹了如何三招搞掛MySQL?,希望對您有用。如果有疑問,可以聯系我們。
本文將介紹三種搞掛MySQL的方式,逗大家一樂,同時也會揭露一些MySQL使用過程中的注意事項和實現原理,以供參考.感興趣的同學可以找一個MySQL實例進行測試.我要說的三種方式分別是:
聲明: 這里介紹的三種方式可以搞掛目前大多數的線上MySQL實例,請謹慎測試.一切后果,本文作者及本網站概不責任哦.
眾所周知,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的都是一群科學家,并且,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.