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

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

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

　　根本原因

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

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

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

　　Instapaper的RDS歷史

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

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

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

　　預(yù)防

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

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

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

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

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

　　備份

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

　　有限服務(wù)恢復(fù)

　　這次事件中沒有一個(gè)好的災(zāi)難恢復(fù)計(jì)劃，因?yàn)橐粋€(gè)關(guān)鍵的文件系統(tǒng)問題MySQL實(shí)例失效，所有的備份也受到了影響。

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

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

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

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

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

　　1. 設(shè)置一個(gè)Aurora閱讀復(fù)制的舊數(shù)據(jù)庫(kù)。我們同意使用Aurora是有風(fēng)險(xiǎn)的，因?yàn)槲覀儧]有對(duì)Instapaper代碼庫(kù)進(jìn)行徹底的測(cè)試，但設(shè)置的阻力很小。閱讀的復(fù)制品大約在24小時(shí)內(nèi)完成。

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

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

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

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

　　全部服務(wù)恢復(fù)

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

　　我們?cè)诓粊G失任何用戶舊文章的情況下進(jìn)行了恢復(fù)，并更改了最近的文章或在從中斷中恢復(fù)后保存的文章。

　　反射

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

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

　　我們堅(jiān)信這一問題很難預(yù)見和預(yù)防，但由于缺乏災(zāi)難恢復(fù)計(jì)劃，從而導(dǎo)致經(jīng)濟(jì)的下降和恢復(fù)的時(shí)間比必要的時(shí)間更長(zhǎng)。此外，還可以從通信的角度，在Pinterest和Amazon Web服務(wù)團(tuán)隊(duì)中采取措施，以便更好地利用相關(guān)的處理資源。

　　行動(dòng)項(xiàng)目

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

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

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

　　關(guān)系數(shù)據(jù)庫(kù)服務(wù)

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

　　此外，RDS團(tuán)隊(duì)對(duì)加速全面恢復(fù)非常有幫助。他們甚至向我們提出了一個(gè)特別請(qǐng)求，以添加關(guān)于ext3支持?jǐn)?shù)據(jù)庫(kù)的一些附加信息。

　　問責(zé)制

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

相關(guān)電子資料下載

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