分析Instapaper宕機原因及故障恢復過程
一項保存網頁以便稍后閱讀的服務，它曾經歷過長時間的中斷，作者作為運營總監給我們講述了故障的原因和恢復過程。
Instapaper服務于周三（2月9日）至2月10日（周四）下午7時30分之間出現了長時間的中斷，我們將Instapaper服務作為一個短期的解決方案，提供了有限的訪問權，同時我們也在努力恢復服務。2月14日，我們完成了服務的全面恢復。
失敗的關鍵系統是我們的MySQL數據庫，該數據庫作為托管解決方案在Amazon的關系數據庫服務（RDS）上運行。下面將討論哪里出了問題，如何解決問題，以及怎樣提高可靠性。
根本原因
簡而言之，數據故障是由2014年4月之前創建的RDS實例的2TB文件大小限制造成的。2月9日（星期三）下午12:30，我們的“書簽”表，存儲了Instapaper用戶保存的文章，超過了2TB文件的大小限制。隨后在書簽表中插入新條目開始拋出以下錯誤：
OperationalError： （OperationalError） （1114， “The table ‘bookmarks’ is full”）
之所以存在這種限制，是因為在2014年4月之前創建的MySQL RDS實例使用了具有2TB文件大小限制的ext3文件系統。而2014年4月以后創建的實例由ext4文件系統支持，并受6TB文件大小限制。
Instapaper的RDS歷史
2013年4月，betaworks從Marco Arment獲得Instapaper。收購后，我們將Instapaper從Softlayer遷移到Amazon Web Services，因為所有betaworks公司都在AWS上運行，因此工程師在該平臺上擁有專業知識。為了執行遷移，betaworks與他們的兩個常規開發承包人一起工作。遷移后，運營被移交給新成立的Instapaper團隊，運營責任落在我們的工程總監身上。2014年10月，我們的工程總監離開公司后，我接手了后期運營。
我們的原始實例在2013年6月創建，在2015年初的備份窗口中遇到一些性能問題。AWS支持是在舊硬件上和舊版本的MySQL v5.6.18上運行。如果我們升級到最新的版本（v5.6.19 +），AWS問題將得到解決。
在2015年3月，我們創建了一個2013年6月的RDS實例的讀取副本，升級了MySQL版本，并在午夜的時候完成了轉換開關操作——大約5分鐘。盡管這個實例是在2014年4月之后創建的，但它作為一個從原始的RDS實例中創建的一個副讀本，因此，它繼承了相同的文件系統和2TB文件大小的限制。
預防
如果不了解2014年4月前的文件大小限制，就很難預見和防止這個問題。據我們所知，RDS控制臺的監控、警報或日志記錄中沒有任何信息可以讓得知正在接近2TB文件的大小限制。即使是現在，也沒有任何跡象表明托管數據庫存在關鍵問題。
如果對文件大小的限制有所了解，那么很可能會在2013年的betaworks承包人的基礎上繼續進行軟層遷移。就我們所知只有兩種方式，作為RDS的客戶，本可以阻止這個問題。
首先，可以將數據庫完全轉儲到磁盤，然后將數據庫恢復到新的RDS實例。在這個場景中，可能需要直接與Amazon一起工作，以將新的RDS實例設置為舊版本的讀取副本，然后執行切換。
另一個選擇是創建一個運行Amazon Aurora的讀取副本，亞馬遜的托管sql兼容數據庫系統。我們之前曾考慮過遷移Aurora（主要是為了節約成本），但是Aurora只在VPC上運行，而Instapaper仍然運行在EC2-classic上。
然而最終，不太可能在不了解局限性的情況下進行這些操作。
備份
RDS的一個重要特性是自動的備份數據庫實例。我們為MySQL數據庫存儲了10天的備份。但是，由于這些備份都是文件系統快照，所以它們也會受到2TB文件大小的限制。
有限服務恢復
這次事件中沒有一個好的災難恢復計劃，因為一個關鍵的文件系統問題MySQL實例失效，所有的備份也受到了影響。
在用AWS支持并與Pinterest網站可靠性工程師討論限制之后，我們了解到唯一出路是使用完整的轉儲和恢復重建2.5 TB數據庫。Pinterest的SRE團隊盡可能快地引導我們通過將Instapaper的生產數據庫提交給由i2.8xlarge實例提供的5.5TB raid-0磁盤。
當思路變得清晰時，轉儲將花費很長時間（第一次花費24小時，第二次使用并行化花費了10個小時），我們開始執行一項應急計劃，從Instapaper存檔中訪問有限的工作狀態來獲得一個實例。這一短期解決方案在停工31小時后投入生產。創建該實例并將其投入生產的總時間大約為6個小時。
由于沒有針對這類事件的計劃，所以對轉儲和恢復數據庫所需的時間沒有很好的把握。對數據庫轉儲的初步估計是6到8小時。但我們使用行數進行了估計，之后學習了前25%的Instapaper書簽只占全部數據的10%。如果知道重建數據庫將是連日的工作，我們需要直接啟動有限的服務恢復，那么我們就可以大大減少初始停機時間。
數據恢復
當服務返回并完成數據轉儲之后，下一步是將所有的轉儲導入到一個不受2TB文件大小限制的實例中。我們在整個周末與RDS工程師緊密合作，以實現兩種并行工作流程：
1. 設置一個Aurora閱讀復制的舊數據庫。我們同意使用Aurora是有風險的，因為我們沒有對Instapaper代碼庫進行徹底的測試，但設置的阻力很小。閱讀的復制品大約在24小時內完成。
2. 創建一個新的MySQL RDS實例，導入所有沒有二級索引（8小時）的數據，并在導入數據之后創建三個二級索引（每個二級索引大約花費16小時）。寫這篇文章的時候，最后一個二級索引仍在創建中。
在認識到二級索引創建時間長得不可接受之后，其中一位Amazon工程師將ext4文件系統安裝到失敗的生產數據庫中，并在ext3文件系統和ext4文件系統之間執行了rsync。rsync在大約8小時內運行，最終為我們提供了一個新的、ext4支持的數據庫實例，并恢復了所有數據和索引。
與臨時生產數據庫同步
使用來自臨時生產數據庫的二進制日志（帶有限的存檔），RDS工程師將新的ext4支持的數據庫建立在臨時生產數據庫上，以便同步周四和周一之間的更改。這個復制的總時間大約是三個小時。
全部服務恢復
一旦擁有新的ext4支持的數據庫，并將完整的數據和索引與臨時生產數據庫同步，最后一步是推廣新數據庫，并部署應用程序代碼以指向新數據庫。
我們在不丟失任何用戶舊文章的情況下進行了恢復，并更改了最近的文章或在從中斷中恢復后保存的文章。
反射
這是任何web應用程序開發人員最糟糕的噩夢。不知道基于文件系統的限制和沒有可見性，不僅使生產數據庫變得無用，也使所有的備份失效。唯一的方法是將數據恢復到一個擁有全新實例的新文件系統上。由于托管實例中唯一的接口是MySQL，這使得在沒有Amazon工程師的直接幫助下，讓類似rsync的文件系統級的解決方案難以實現，因此變得更加復雜。
即使已經完美地執行了全新實例，從診斷出問題到完全重建數據庫的那一刻起，總停機時間至少是10個小時。當然，這遠遠少于總停機時間和五天有限訪問的時間，但只是希望在一個完美的世界中說明這類問題的嚴重性。
我們堅信這一問題很難預見和預防，但由于缺乏災難恢復計劃，從而導致經濟的下降和恢復的時間比必要的時間更長。此外，還可以從通信的角度，在Pinterest和Amazon Web服務團隊中采取措施，以便更好地利用相關的處理資源。
行動項目
作為在Pinterest上回顧過程的一部分，我們定義了一個更好的工作流，適用于系統范圍的Instapaper中斷，使問題立即升級到Pinterest的站點可靠性工程團隊。
另外，我們將更積極地測試MySQL備份。過去每三個月測試一次備份，現在將每個月測試一次。
上述兩項操作都不會阻止問題的發生，但是它們會在發生故障時加速我們的響應時間，并且是很好的實踐。
關系數據庫服務
我們現在將繼續使用Amazon的關系數據庫服務。盡管在沒有警告或可見性的情況下體驗問題是令人沮喪的，但是RDS一直是一種可靠而健壯的服務，可以在未來的幾年時間內使用，并處理快照、讀取復制和其他任務，而不需要從Instapaper團隊獲得任何工程開銷。
此外，RDS團隊對加速全面恢復非常有幫助。他們甚至向我們提出了一個特別請求，以添加關于ext3支持數據庫的一些附加信息。
問責制
我需要對事故和停工負責，雖然關于2TB限制的信息沒有直接向我提供，但有責任了解在日常操作中使用的技術局限性，即使這些技術是由另一家公司托管的。此外，我還需要對缺乏適當的災難恢復計劃負責，并將與Pinterest的網站可靠性工程團隊密切合作，以確保我們從失敗中徹底恢復過來，避免再次發生。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%