911
揭秘：Instapaper基於AWS上MySQL曆時一周的恢複
正文：
Instapaper服務在2月9日（星期三）12:30到2月10日19:30發生長時間的中斷。 在做完全恢複的同時，我們首先利用歸檔恢複到一個時間點，通過有限的訪問來保證服務的連續，而昨天（2月14），我們 已經完成了所有的恢複。
遭遇故障的主係統是MySQL數據庫，這套係統我們以托管的方式運行在Amazon的關係型數據庫服務上（RDS）。通過這篇文章我將深入剖析故障發生的原因，詳細的處理過程，以及為了今後更高效可靠運行我們的應對方案。
原因剖析：
簡單來講，數據庫的故障時由於在2014年4月之前創建的RDS實例中的文件上限導致的。2月9號12:30，當Instapaper用戶在存放文章的 bookmarks 表上插入數據並做保存的時候，使得對應的數據文件大小超出了2TB，隨後其他用戶在向該表中插入新的條目的過程中，收到如下報錯：
存在2TB上限的根本原因是，該MySQL RDS實例使用了ext3文件係統，該文件係統的最大上限是2TB，而之後創建的實例則使用了ext4文件係統，其對象可以使用的文件大小的上限為6TB。
Instapaper RDS history
-
2013年4月，betaworks 從Marco Arment 收購了Instapaper，之後我們將Instapaper從軟件層遷移至 Amazon 的Web 服務上，這是因為所有的betaworks 的企業都運行在AWS上，這樣使得AWS上運行的項目都有技術支撐。遷移過程是由betaworks和他們的兩個常規DevOps合作商一起完成的。而之後所有在Instapaper的操作由新組建的團隊一起完成，其責任是由當時的團隊管理者承擔，後來2014年10月，該管理者離開了公司，我就從他那裏接管了後續的事情。
-
故障係統最初的實例是在2013年6月份創建的，2015年初做備份的時候遇到一些性能問題，在經過AWS的技術支持確認後，判斷當時使用的硬件和數據庫版本過舊，根據他們的建議，如果我們將MySQL數據庫進行版本升級到v5.6.19+，就可以解決這個問題。
-
2015年3月，我們對最初創建的實例做了一個隻讀的副本複製，為了減少停機時間，對版本的升級和係統的切割過程是在半夜完成的，當時用了不到5分鍾時間。
-
雖然這個隻讀的副本實例是在2014年4月之後創建的，但由於是之前實例的拷貝，理所當然地繼承了老實例的ext3文件係統，上限仍然為2TB。
故障防範
由於對老的文件係統的限製不清楚，因此很難預料到這次事故，我們並沒有做任何的防範措施。就目前的情況分析，在RDS的控製台並沒有任何形式的監控、告警或者日誌能夠讓我們事先知道我們即將達到2TB的文件上限，也便於及時采取措施。甚至在故障發生後的今天，對於我們遭遇的嚴重問題，仍然沒有任何說明和呈現出來。
如果我們能夠事先知道文件的上限，當時就不會對2013年的老實例進行隻讀的副本遷移，以現在的角度來看，我們作為RDS的用戶，有以下兩種途徑本可以避免這次的事故。
第一種，我們可以將舊係統的數據做一個完整的dump到磁盤，然後通過還原創建新的RDS實例，我們可能需要跟Amazon一起合作，創建一個新的隻讀的RDS實例，然後再實現切割。
第二種方案是將隻讀的副本運行在Amazon Aurora上，它是Amazon的托管SQL兼容的數據庫係統，我們之前基於成本是考慮過遷移到Aurora上的，然而Aurora隻能在一個VPC上運行，而Instapaper仍然運行在EC2-classic上。因此作罷。
但這些方案最終都沒有執行，因為我們根本不清楚有這個文件上限存在。
關於備份
RDS的一個很大的好處在於對數據庫係統做每日自動備份，我們係統的備份保留了最近十天的。然而，由於這些備份仍然是整個文件係統的快照，同樣具有2TB的文件上限。
服務恢複受到限製
在這次由於文件係統故障導致的MySQL實例的故障中，我們沒有做有效的災難恢複方案，文件係統的限製同樣導致了備份的限製。
故障發生後，我們與AWS技術支持人員進行長時間電話會談，與Pinterest站點負責可靠性的工程師討論了關於文件係統的限製，認識到當前唯一的解決方案是使用完全轉儲和恢複來重建大小為2.5TB的數據庫。Pinterest的SRE團隊以盡快的速度指導我們將Instapaper的生產數據庫轉儲到由i2.8xlarge實例提供的5.5TB RAID-0磁盤。
但是在我們進行dump的時候發現，這個過程實在太漫長了，第一階段的dump花了將近24個小時，第二階段因為開了並行，但也用了10小時才完成。於是我們決定實施連續性方案，利用當前歸檔恢複到一個時間點，提供有限訪問來保障Instapaper的運行。在故障發生後的31小時後，我們才開始實施了這個方案。之後創建實例並投入生產使用又花了將近6個小時的時間。
由於我們沒有對這類故障提前做應對方案，也就沒有考慮到通過轉儲和還原的方式所需要的時間成本。我們最初對於轉儲時間的預估是6到8個小時，但我們的預測是基於行數的，在操作的過程中發現以行數計算的25%的數據事實上隻是實際數據的10% 左右。如果我們早知道重建數據庫需要花這麼大的代價，我們可能會直接啟動有效的服務恢複，從而在很大程度上減少最初的停機時間。
數據還原
當做好服務備份，數據轉儲完成的時候，下一步就是將所有的轉儲數據導入到新的文件係統，我們跟RDS的項目團隊密切合作，完成了以下兩項任務。
1、創建原係統的隻讀副本。我們在老係統上沒有測試過，因此本次使用Aurora是存在很大的風險的。而實際的隻讀副本從創建到投入使用花了24個小時。
2、創建MySQL數據庫的RDS實例，不通過二級索引庫將所有的數據導入，這大概花了8個小時；後麵又創建了3個二級索引庫，每個索引庫的創建時間是16小時，在我發布這篇文章（2月14）的時候，最有一個索引庫海正在創建中。
當我們意識到創建二級索引庫的時間是如此長，Amazon的工程師將一個ext4的文件係統掛到故障數據庫上，試圖在舊的ext3文件係統和新的ext4文件係統上做異步的數據傳輸。這個過程大概花了8小時，最終就是通過這種方式將所有的數據和索引完整備份並恢複到了ext4多文件係統上。
Syncing with temporary production database
為了同步故障期間（上周四到周一）的數據，RDS的工程師利用有限歸檔下恢複得到的臨時生產數據庫的二進製日誌文件，基於行複製創建了一個新的ext4文件係統的備份數據庫，這個過程用時三小時。
完整的服務還原
當我們將基於歸檔的臨時數據庫的所有數據和索引都同步到exy4文件係統的備份數據庫之後，最後一步是修改相關配置將應用指向新庫，實現交接。
在我們的整個還原過程中，對用戶早期的文章沒有造成損失，有數據損失的是後麵修改過的文章和故障發生後寫的文章。
故障影響
這是所有網頁應用程序開發商的噩夢。對於文件係統的上限我們事先毫不知情並且沒有任何預防措施，不僅僅導致數據庫的故障，連同備份也是不全的。事後我們唯一的解決方案就是將現有數據恢複到基於全新文件係統的全新數據庫上。
這個方案後麵又被複雜化了，由於我們唯一的接口的托管實例是MySQL數據庫，這使文件係統級像rsync一樣的解決方案不可能在沒有Amazon工程師的直接幫助完成的。
從我們診斷出問題到重建數據庫完成，哪怕整個過程非常流暢，也需要至少10個小時才能完成，當然這聽起來比總共31個小時的宕機時間和連續5天的訪問限製好很多。我隻是想說明一下這類問題的嚴重性，哪怕是在最完美的情況下，仍然是一個很棘手的問題。
我們堅持認為這個問題很難預見和防範，但是缺乏這種類型故障的災難恢複計劃導致了比必要更長的停機和恢複時間。 此外，為了更好地利用可用資源，我們可以事先跟一些專家，包括在Pinterest內部和Amazon網絡服務團隊，加強溝通，這有利於故障後問題的快速處理。
防範措施
在總結這次事件的時候，我們為係統範圍的Instapaper故障製定了更好的解決方案流程，將問題升級到Pinterest站點的可靠性工程團隊。
除此，我們會加強對mysql數據庫備份的校驗，以前是每三個月做一次校驗，今後的頻率將提升為每個月做一次。
不管以上的措施能不能防範這樣的事故發生，但至少會在今後麵對類似故障的時候減少響應和處理時間。
Relational database service（關於RDS的聲明）
我們將會繼續使用Amazon的關係型數據庫服務（RDS），雖然這次的事故的確讓我們產生失望和顧慮，但這些年在使用Amazon的服務的過程中，作為用戶我們不得不承認Amazon是一家可靠並強大的服務公司，RDS提供了快照、故障轉移、隻讀複製等多種優質服務，而這些都遠超出了Instapaper團隊所能做的。
此外，RDS團隊在加速我們的完全恢複方麵做出了巨大的幫助， 以Instapaper事故為鑒，他們在服務中添加關於ext3文件係統一些警示和相關信息。
關於責任
關於這件事我認為我該承擔全部的責任，盡管關於ext3文件係統的限製我並不清楚，但是對於一項我每天都會接觸到的技術來說，哪怕是被托管，我也應該要考慮到這些限製的。除此而外，沒有提前做任何災難恢複的預案也是我的責任，今後將會加強與Pinterest 站點的可靠性團隊的合作，保證下次再遇到類似的故障的時候能夠遊刃有餘，有備無患。
以下分享一些網友的評論：
感謝Brian詳細的分析和闡釋，同樣作為AWS的用戶，這篇文章給了我很大的警示，今後我將會加強災難恢複的預案和防範。
-by Ron Heft
我很喜歡Instapaper，從Marco推出的那一天，我幾乎每天都會使用，現在也購買其中的一些服務，並享受該平台所創造的一切便利和美好。而在這次事故中，看到Instapaper的負責人能夠公平公正地分析，並願意自己承擔責任，這更加讓我佩服。
-by John Philpin
感謝這篇文章。使我有機會從別人的錯誤中學習，作為一個Instapaper用戶，我很高興你能夠這麼快恢複服務和數據。 我自己從中學到的主要是，也許在某個時候，你就會遇到的嚴峻的現實問題，要時刻謹記，雲隻是別人的電腦，要有安全意識。 雖然我沒有太多使用RDS，但我不希望在使用任何托管的數據庫平台時還要去關心文件係統大小限製。希望雲服務提供商能夠考慮這一點
-by Jamison Dance
我們總是忙於處理各種事情，根本沒有時間去總結思考和學習，在這次的事故中，其實我並不認為易地而處，我們會處理多好。感謝作者能夠坦誠地描述事件的來龍去脈將故障透明化，也感謝給作為商業服務開發商的我們提出警示，我們也會加強對災難恢複的預案和防範措施製定。
-by Steve Johnson
故障完美地解決令人欣慰，而不因事故失去的合作才最難能可貴。如果雙贏是完美的最終目的，那麼理解和合作，則是最重要的途徑。
文章轉自數據和雲公眾號，原文鏈接
最後更新：2017-07-17 17:32:58