運營總監講述Instapaper宕機原因及故障恢復過程詳解

作者丨 Brian Donohue

翻譯丨黑色巧克力

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月，我們的工程總監離開公司後，我接手了後期運營。

在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的網站可靠性工程團隊密切合作，以確保我們從失敗中徹底恢復過來，避免再次發生。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！