一項保存網(wǎng)頁以便稍后閱讀的服務，它曾經(jīng)歷過長時間的中斷，作者作為運營總監(jiān)給我們講述了故障的原因和恢復過程。

　　Instapaper服務于周三（2月9日）至2月10日（周四）下午7時30分之間出現(xiàn)了長時間的中斷，我們將Instapaper服務作為一個短期的解決方案，提供了有限的訪問權(quán)，同時我們也在努力恢復服務。2月14日，我們完成了服務的全面恢復。

　　失敗的關鍵系統(tǒng)是我們的MySQL數(shù)據(jù)庫，該數(shù)據(jù)庫作為托管解決方案在Amazon的關系數(shù)據(jù)庫服務（RDS）上運行。下面將討論哪里出了問題，如何解決問題，以及怎樣提高可靠性。

　　根本原因

　　簡而言之，數(shù)據(jù)故障是由2014年4月之前創(chuàng)建的RDS實例的2TB文件大小限制造成的。2月9日（星期三）下午12:30，我們的“書簽”表，存儲了Instapaper用戶保存的文章，超過了2TB文件的大小限制。隨后在書簽表中插入新條目開始拋出以下錯誤：

　　OperationalError： （OperationalError） （1114， “The table ‘bookmarks’ is full”）

　　之所以存在這種限制，是因為在2014年4月之前創(chuàng)建的MySQL RDS實例使用了具有2TB文件大小限制的ext3文件系統(tǒng)。而2014年4月以后創(chuàng)建的實例由ext4文件系統(tǒng)支持，并受6TB文件大小限制。

　　Instapaper的RDS歷史

　　2013年4月，betaworks從Marco Arment獲得Instapaper。收購后，我們將Instapaper從Softlayer遷移到Amazon Web Services，因為所有betaworks公司都在AWS上運行，因此工程師在該平臺上擁有專業(yè)知識。為了執(zhí)行遷移，betaworks與他們的兩個常規(guī)開發(fā)承包人一起工作。遷移后，運營被移交給新成立的Instapaper團隊，運營責任落在我們的工程總監(jiān)身上。2014年10月，我們的工程總監(jiān)離開公司后，我接手了后期運營。

　　我們的原始實例在2013年6月創(chuàng)建，在2015年初的備份窗口中遇到一些性能問題。AWS支持是在舊硬件上和舊版本的MySQL v5.6.18上運行。如果我們升級到最新的版本（v5.6.19 +），AWS問題將得到解決。

　　在2015年3月，我們創(chuàng)建了一個2013年6月的RDS實例的讀取副本，升級了MySQL版本，并在午夜的時候完成了轉(zhuǎn)換開關操作——大約5分鐘。盡管這個實例是在2014年4月之后創(chuàng)建的，但它作為一個從原始的RDS實例中創(chuàng)建的一個副讀本，因此，它繼承了相同的文件系統(tǒng)和2TB文件大小的限制。

　　預防

　　如果不了解2014年4月前的文件大小限制，就很難預見和防止這個問題。據(jù)我們所知，RDS控制臺的監(jiān)控、警報或日志記錄中沒有任何信息可以讓得知正在接近2TB文件的大小限制。即使是現(xiàn)在，也沒有任何跡象表明托管數(shù)據(jù)庫存在關鍵問題。

　　如果對文件大小的限制有所了解，那么很可能會在2013年的betaworks承包人的基礎上繼續(xù)進行軟層遷移。就我們所知只有兩種方式，作為RDS的客戶，本可以阻止這個問題。

　　首先，可以將數(shù)據(jù)庫完全轉(zhuǎn)儲到磁盤，然后將數(shù)據(jù)庫恢復到新的RDS實例。在這個場景中，可能需要直接與Amazon一起工作，以將新的RDS實例設置為舊版本的讀取副本，然后執(zhí)行切換。

　　另一個選擇是創(chuàng)建一個運行Amazon Aurora的讀取副本，亞馬遜的托管sql兼容數(shù)據(jù)庫系統(tǒng)。我們之前曾考慮過遷移Aurora（主要是為了節(jié)約成本），但是Aurora只在VPC上運行，而Instapaper仍然運行在EC2-classic上。

　　然而最終，不太可能在不了解局限性的情況下進行這些操作。

　　備份

　　RDS的一個重要特性是自動的備份數(shù)據(jù)庫實例。我們?yōu)镸ySQL數(shù)據(jù)庫存儲了10天的備份。但是，由于這些備份都是文件系統(tǒng)快照，所以它們也會受到2TB文件大小的限制。

　　有限服務恢復

　　這次事件中沒有一個好的災難恢復計劃，因為一個關鍵的文件系統(tǒng)問題MySQL實例失效，所有的備份也受到了影響。

　　在用AWS支持并與Pinterest網(wǎng)站可靠性工程師討論限制之后，我們了解到唯一出路是使用完整的轉(zhuǎn)儲和恢復重建2.5 TB數(shù)據(jù)庫。Pinterest的SRE團隊盡可能快地引導我們通過將Instapaper的生產(chǎn)數(shù)據(jù)庫提交給由i2.8xlarge實例提供的5.5TB raid-0磁盤。

　　當思路變得清晰時，轉(zhuǎn)儲將花費很長時間（第一次花費24小時，第二次使用并行化花費了10個小時），我們開始執(zhí)行一項應急計劃，從Instapaper存檔中訪問有限的工作狀態(tài)來獲得一個實例。這一短期解決方案在停工31小時后投入生產(chǎn)。創(chuàng)建該實例并將其投入生產(chǎn)的總時間大約為6個小時。

　　由于沒有針對這類事件的計劃，所以對轉(zhuǎn)儲和恢復數(shù)據(jù)庫所需的時間沒有很好的把握。對數(shù)據(jù)庫轉(zhuǎn)儲的初步估計是6到8小時。但我們使用行數(shù)進行了估計，之后學習了前25%的Instapaper書簽只占全部數(shù)據(jù)的10%。如果知道重建數(shù)據(jù)庫將是連日的工作，我們需要直接啟動有限的服務恢復，那么我們就可以大大減少初始停機時間。

　　數(shù)據(jù)恢復

　　當服務返回并完成數(shù)據(jù)轉(zhuǎn)儲之后，下一步是將所有的轉(zhuǎn)儲導入到一個不受2TB文件大小限制的實例中。我們在整個周末與RDS工程師緊密合作，以實現(xiàn)兩種并行工作流程：

　　1. 設置一個Aurora閱讀復制的舊數(shù)據(jù)庫。我們同意使用Aurora是有風險的，因為我們沒有對Instapaper代碼庫進行徹底的測試，但設置的阻力很小。閱讀的復制品大約在24小時內(nèi)完成。

　　2. 創(chuàng)建一個新的MySQL RDS實例，導入所有沒有二級索引（8小時）的數(shù)據(jù)，并在導入數(shù)據(jù)之后創(chuàng)建三個二級索引（每個二級索引大約花費16小時）。寫這篇文章的時候，最后一個二級索引仍在創(chuàng)建中。

　　在認識到二級索引創(chuàng)建時間長得不可接受之后，其中一位Amazon工程師將ext4文件系統(tǒng)安裝到失敗的生產(chǎn)數(shù)據(jù)庫中，并在ext3文件系統(tǒng)和ext4文件系統(tǒng)之間執(zhí)行了rsync。rsync在大約8小時內(nèi)運行，最終為我們提供了一個新的、ext4支持的數(shù)據(jù)庫實例，并恢復了所有數(shù)據(jù)和索引。

　　與臨時生產(chǎn)數(shù)據(jù)庫同步

　　使用來自臨時生產(chǎn)數(shù)據(jù)庫的二進制日志（帶有限的存檔），RDS工程師將新的ext4支持的數(shù)據(jù)庫建立在臨時生產(chǎn)數(shù)據(jù)庫上，以便同步周四和周一之間的更改。這個復制的總時間大約是三個小時。

　　全部服務恢復

　　一旦擁有新的ext4支持的數(shù)據(jù)庫，并將完整的數(shù)據(jù)和索引與臨時生產(chǎn)數(shù)據(jù)庫同步，最后一步是推廣新數(shù)據(jù)庫，并部署應用程序代碼以指向新數(shù)據(jù)庫。

　　我們在不丟失任何用戶舊文章的情況下進行了恢復，并更改了最近的文章或在從中斷中恢復后保存的文章。

　　反射

　　這是任何web應用程序開發(fā)人員最糟糕的噩夢。不知道基于文件系統(tǒng)的限制和沒有可見性，不僅使生產(chǎn)數(shù)據(jù)庫變得無用，也使所有的備份失效。唯一的方法是將數(shù)據(jù)恢復到一個擁有全新實例的新文件系統(tǒng)上。由于托管實例中唯一的接口是MySQL，這使得在沒有Amazon工程師的直接幫助下，讓類似rsync的文件系統(tǒng)級的解決方案難以實現(xiàn)，因此變得更加復雜。

　　即使已經(jīng)完美地執(zhí)行了全新實例，從診斷出問題到完全重建數(shù)據(jù)庫的那一刻起，總停機時間至少是10個小時。當然，這遠遠少于總停機時間和五天有限訪問的時間，但只是希望在一個完美的世界中說明這類問題的嚴重性。

　　我們堅信這一問題很難預見和預防，但由于缺乏災難恢復計劃，從而導致經(jīng)濟的下降和恢復的時間比必要的時間更長。此外，還可以從通信的角度，在Pinterest和Amazon Web服務團隊中采取措施，以便更好地利用相關的處理資源。

　　行動項目

　　作為在Pinterest上回顧過程的一部分，我們定義了一個更好的工作流，適用于系統(tǒng)范圍的Instapaper中斷，使問題立即升級到Pinterest的站點可靠性工程團隊。

　　另外，我們將更積極地測試MySQL備份。過去每三個月測試一次備份，現(xiàn)在將每個月測試一次。

　　上述兩項操作都不會阻止問題的發(fā)生，但是它們會在發(fā)生故障時加速我們的響應時間，并且是很好的實踐。

　　關系數(shù)據(jù)庫服務

　　我們現(xiàn)在將繼續(xù)使用Amazon的關系數(shù)據(jù)庫服務。盡管在沒有警告或可見性的情況下體驗問題是令人沮喪的，但是RDS一直是一種可靠而健壯的服務，可以在未來的幾年時間內(nèi)使用，并處理快照、讀取復制和其他任務，而不需要從Instapaper團隊獲得任何工程開銷。

　　此外，RDS團隊對加速全面恢復非常有幫助。他們甚至向我們提出了一個特別請求，以添加關于ext3支持數(shù)據(jù)庫的一些附加信息。

　　問責制

　　我需要對事故和停工負責，雖然關于2TB限制的信息沒有直接向我提供，但有責任了解在日常操作中使用的技術局限性，即使這些技術是由另一家公司托管的。此外，我還需要對缺乏適當?shù)臑碾y恢復計劃負責，并將與Pinterest的網(wǎng)站可靠性工程團隊密切合作，以確保我們從失敗中徹底恢復過來，避免再次發(fā)生。

相關電子資料下載

• 常用于緩存處理的機制總結(jié) 如何避免緩存雪崩問題？ 24
• 觸發(fā)器的基本原理、應用場景及優(yōu)缺點 83
• AI大模型對數(shù)據(jù)存儲技術的發(fā)展趨勢 64
• 訪問控制中PIP的典型流程和關鍵點思考 60
• 物證管理系統(tǒng)|智物證DW-S404是一套成熟系統(tǒng) 44
• Python 梯度計算模塊如何實現(xiàn)一個邏輯回歸模型 93
• TinyDB ：一個純Python編寫的輕量級數(shù)據(jù)庫 58
• mysql經(jīng)典面試題及答案 63
• 人大金倉獲評“2023年度軟件和信息技術服務名牌企業(yè)” 100
• 人大金倉亮相第40屆CCF中國數(shù)據(jù)庫學術會議（NDBC 2023） 119