從史上八大MySQL宕機事故中學到的經驗

從史上八大MySQL宕機事故中學到的經驗

2013年06月25日09:24 來源： CSDN 做者：CSDN 摘譯 編輯： 王玉圓  我要評論(0)

        【IT168 評論】本文列舉了史上八大MySQL宕機事件緣由、影響以及人們從中學到的經驗，文中用地震級數來類比宕機事件的嚴重性和後果，排在最嚴重層級前兩位的是因爲亞馬遜AWS宕機故障(至關於地震十級和九級)。

　　1、Percona網站宕機事件

　　震級：3

　　發生時長：2011年7月11日

　　持續時長：很多天

　　地點：加州Pleasanton(幸福屯)

　　宕機緣由：Percona網站主服務器上的3塊硬盤損壞，同時由於人員變動，致使未能如預期地恢復，多個網站資產所以下線數小時到數天不等，影響其軟件下載及交易。

　　經驗：備份不必定永遠正常，不該該對其抱有過多期待。

　　2、GitHub服務中斷

　　震級：4

　　發生時間：2012年9月10-11日

　　持續時長：1:46小時

　　地點：加州聖弗朗西斯科

　　宕機緣由：GitHub將一對古老的、基於DRBD的MySQL服務器替換成一個擁有3個節點的集羣。在合併到新系統時，「活動的」數據庫自動出現了多個故障轉移(failover)，同時又由於集羣管理軟件的錯誤操做致使性能降低，最終形成網站宕機。

　　經驗：GitHub修改了Pacemaker配置來保證故障轉移僅僅能夠被運維人員控制。

　　3、Journal Space全部數據丟失及網站關閉

　　震級：5

　　發生時間：2009年1月5日

　　持續時長：無限期

　　宕機緣由：Journal Space是一個擁有6年曆史的博客平臺，基於MySQL開發，其惟一的數據庫備份機器由RAID系統維護。最終網站的數據因前員工的報復行爲被重寫，最終致使全部用戶數據丟失以及網站關閉。

　　經驗：永遠不要把驅動器鏡像當作備份——它能防範物理故障帶來的問題，可是不提供時間點恢復功能。

　　4、PHPFog共享數據庫運行中斷

　　震級：6

　　發生時間：2012年10月8日

　　持續時長：8小時

　　地點：俄勒岡州波特蘭

　　宕機緣由：PHPFog將用戶數據合併到一個新的共享數據庫服務上，可是在合併過程當中遭受過多的堆疊鏈接，最終共享數據庫中止響應，所以在共享數據庫從快照中恢復前一直處於服務不穩定狀態。從問題發生到解決一共歷時8小時。

　　經驗：這一事件後，PHPFog加速Amazon RDS用戶遷移活動。

　　5、Couch Surfing因MySQL數據庫故障致使服務關閉

　　震級：7

　　發生時間：2006年6月

　　地點：加州聖弗朗西斯科

　　持續時長：1個月

　　宕機緣由：流行社交網站Couch Surfing曾擁有90000名用戶，在2006年遭遇了一場嚴重的硬盤問題，在試圖恢復數據時發現數據庫增值備份遭遇問題。其MySQL數據庫以及應用關鍵部分丟失，所以創始人最終關閉了這項服務，隨後用戶社區又將它重啓。

　　經驗：任何MySQL系統必須有一個以上備份服務器;天天都必須驗證MySQL備份進程。

　　6、magnolia因丟失主數據庫和備份致使最終沒法徹底恢復

　　震級：7

　　發生時間：2009年1月30日

　　地點：加州聖弗朗西斯科

　　持續時長：無限期

　　宕機緣由：Magnolia和Delicious同樣，是一個流行的書籤服務，基於MySQL數據庫。該服務在因爲硬盤損壞以及備份系統的錯誤，丟失了主數據庫和備份，最終沒法徹底恢復。

　　經驗：確保硬件的可靠性很是重要;備份系統是否可行必須獲得充分的驗證。

　　7、Amazon RDS宕機事件

　　震級：9

　　發生時間：2012年6月29日

　　持續時長：3小時

　　地點：弗吉尼亞州北部

　　用戶影響：亞馬遜EC2雲計算服務以及包括Netflix公司、Heroku、Pinterest、 Quora、HootSuite和Instagram等。

　　宕機緣由：一個被稱爲derecho的強雷暴天氣系統經過弗吉尼亞州北部，使得亞馬遜在該地區的設施失去了動力，發電機不能正常運行，消耗應急電源的不間斷電源(電源)系統，從而致使運行在Amazon RDS上的大概上千個MySQL數據庫宕機。

　　經驗：擴大7*24小時工程師支持團隊規模，發生電源系統故障、UPS啓動以前徹底支持手動操做開啓發電機開關。

　　8、Amazon RDS宕機事件

　　震級：10

　　發生時間：2011年4月21日

　　持續時長：48小時

　　地點：弗吉尼亞州北部

　　用戶影響：致使使用AWS平臺的Reddit、Foursquare、Hootsuite、Quora以及其餘多家社交網絡服務商成爲「受害者」 。

　　宕機緣由：亞馬遜修改網絡設置，同時在對主網絡升級擴容過程當中，工程師不慎將主網數據所有切換到從網，因爲從網帶寬較小，而它的設計目的並不是用於主網容災或備份，所以致使網絡堵塞，全部EBS(Elastic Block Store)節點通訊所有中斷，致使存儲着數據和日誌的MySQL數據庫宕機，其中運行在一個可用區域裏41%的MySQL數據庫宕機24小時，14.6%宕機48小時。

　　經驗：亞馬遜從新審計了網絡設置修改流程、加強自動化運維手段以及容災架構設計。

摘自：http://tech.it168.com/a2013/0625/1499/000001499210.shtml