514
技術社區[雲棲]
雲服務真的靠譜嗎？ AWS 用戶中斷31小時僅恢複6周數據
網絡剪報服務商 - Instapaper 遭受了超過31小時的服務中斷，而且他們聲明還需要一個星期的數據庫恢複時間。
Instapaper 是一個網絡內容收藏站，允許用戶保存“所有有趣的文章，視頻，烹飪食譜，歌詞或瀏覽時遇到的任何其他內容”。
但是他們的服務在2月8日中斷，官方博客已經在2月9日聲明了事情的來龍去脈。
Instapaper 說：我們花費了數個小時和雲服務商電話溝通，服務商申明我們的數據庫遇到了係統限製，不能提供文章保存服務。我們唯一的選擇是導出所有數據，導入新建的數據庫。
Instapaper 還說：我們位2016年99.3%的可用性自豪，我們確保用戶的數據沒有丟失。但是恢複還需要時間。
在經過了 31 個小時的業務中斷之後，Instapaper 宣布經過努力，重建數據庫實例使得服務重新上線，但是數據僅恢複到最近的 6 個星期，從2016-12-20之後的內容可以訪問了。
全部的數據恢複要持續到2月17日，好吧，這是整整10天，用10天去恢複數據，使得用戶能夠訪問自己所有的收藏，這個恢複時間也是相當的驚人！
從該網站的腳本就可以看到，Instapaper 托管在 AWS 雲平台上：
鑒於我們的職業性，需要來分析一下故障的原因，並引以為戒。
Instapaper 的數據庫是 MySQL 數據庫。在該公司工程師的博客上，曾經描述過該網站的架構。
Instapaper 最初的全文檢索使用一台 Sphinx 服務器直接和 MySQL 聯合提供搜索，這個搜索使用 AWS EC2 大約70GB 內存，4TB 存儲的資源：
Instapaper’s full-text search is available to Premium subscribers only, and it was originally set up as a Sphinx server to be used in conjunction with Instapaper’s MySQL database.
Since making the transition to Amazon Web Services, Instapaper’s full-text search has run on a single m2.4xlarge EC2 instance, a memory-optimized instance with ~70GB of RAM. The Sphinx full-text indexes are stored in a 4TB mounted volume, which is a RAID10 array configured as 8 1TB EBS volumes.
Instapaper 的索引數據量（數據庫的數據量未知），在2016年5月時數據量2.2TB，每月增長約110GB，後來實在慢的不行，最後選擇了 AWS 的 elasticsearch cluster來承載這項服務。
雲和恩墨的 MySQL 專家對有限的信息做了分析：
1. 數據庫當時，實際上是無法寫入數據而非實例掛掉，並且最後的雲服務商給出的原因是操作係統限製。從結果逆推原因，會導致數據無法寫入而非實例掛掉的，隻能是文件存儲相關的限製了（內存限製超標的話，會swap變很慢或者直接被oom，cpu計算量的限製，也隻是會變慢），這個限製來源很多，操作係統文件係統限製（比如x86的4GB），用戶配額限製（文件大小），磁盤容量限製，文中並沒有詳細提到具體限製來源，隻是交代為操作係統限製。
2. 直接決定的處理方式是先導出，之後導入。從最終結果看由於恢複時間過長，並沒有作為現在的應急措施，實際上是回退到兩個月前的備份（文中提到故障數據庫隻保存六周的數據，看來是直接使用曆史歸檔數據庫提供服務了，基本說明並且當前數據庫沒有任何備份或者有效備份）。一般來說，MySQL在數據無法寫入的時候，實際上的確可以嚐試使用select導出來拯救數據，隻是並不能保證一定可以成功。
3. 文中提到整個數據庫還在導出中，按照時間估計，需要9天時間導出整個故障數據庫，猜測導出慢的主要原因：
文檔類大型數據，一般采用text等格式，存儲的時候會多一跳文件指針。
（猜測）如果采用mysqldump導出，這個軟件是純粹的單線程工具，速度肯定會很慢。
超大數據表的導出，文件指針的跳轉本身代價就不小。
建議：
1. 備份。從結果看，生產數據庫沒有任何備份或者有效備份。
2. 雲數據庫服務限製，自運維數據庫類似的問題，如果在打開雙1（或者哪怕innodb_flush_log_at_trx_commit=1）的情況下，直接拷貝數據文件出來就能恢複數據庫。
2017 似乎是數據庫多災多難的一年，新年伊始，就有很多故事和事故湧現出來，理一理最近幾件事：
還有，如果這個 MySQL 有一個 Slave 備庫幸存，該有多好啊？當然即使是 Oracle 數據庫 ，配備 DataGuard 也並不多，參考《2016年度中國Oracle數據庫使用現狀分析報告》：
閑言少敘，數據庫的“備份重於一切”，趕緊用 Bethune （ https://bethune.enmotech.com ）為你的數據庫做個巡檢壓壓驚吧，發現潛在問題，早日消除安全隱患！
最後更新：2017-07-17 17:03:30