Facebook如何實現PB級別資料庫自動化備份

發表於2013-05-15

| 2013-05-15 21:10   收藏: 1    

Facebook的MySQL資料庫,是世界上最龐大的MySQL資料庫之一,在不同地區有數千個資料庫伺服器。因此,備份對他們來說是個巨大的挑戰。為了解決這個問題,他們構建了一個高度自動化、非常有效的備份系統,每週移動多個PB的資料。Facebook資料團隊的Eric Barrett透過一篇文章分享了他們的做法。

他們沒有采用大量前載(front-loaded)測試,而是強調快速檢測失敗,並且進行快速、自動化糾正。部署幾百個資料庫伺服器,只需很少人力干預。使用下面的三個措施,他們做到了有節奏的增長,同時具備支援上十億使用者的靈活性。

措施1:二進位制日誌和mysqldump

第一道防線稱為“措施1”,或“機架”備份(rack backup),簡稱RBU。在每個資料庫機架上,不論其型別為何,都有兩個RBU儲存伺服器。以RBU作為資料庫伺服器放在同一個機架中,這可以保證最大的頻寬和最小的延遲,它們同時可以作為快取,在備份的下個措施使用。

收集二進位制日誌,是這些伺服器的工作之一。二進位制日誌會不斷以流形式,透過模擬從程式(simulated slave process)輸送到RBU主機中。這樣一來,不需要執行mysqld,RBU就可以接收到同樣的更新作為複製版本。

在RBU上儲存同步的二進位制日誌很重要:如果一個主資料庫伺服器離線,該伺服器上的使用者將無法更新狀態或是上傳照片。出現問題後,他們需要保證修復時間越短越好。有可用的二進位制日誌,就能讓他們在數秒內啟動另一個資料庫作為主資料庫。由於RBU中有秒級的二進位制日誌,即使某個舊主資料庫完全不可用,也沒有關係,只要利用將記錄下的事務恢復到上一個備份中即可完成立即恢復。

RBU伺服器的第二個工作是執行傳統備份。MySQL備份有兩種方式:二進位制和邏輯(mysqldump)。Facebook使用邏輯備份,因為它與版本無關,提供更好的資料完整性,更緊湊,恢復起來更省事。不過,當為某個資料庫構建全新複製時,他們仍然使用二進位制複製。

mysqldump的一個主要好處是:磁碟上的資料損壞不會影響到備份中。如果磁碟某個扇區出現問題,或是寫入錯誤,InnoDB頁面校驗和就會出錯。在組合備份流時,MySQL會從記憶體中讀取正確的內容,或是去磁碟讀取,然後遇到錯誤的校驗和,停止備份(以及資料庫程式)。mysqldump的問題是:汙染用來快取InnoDB塊的LRU快取。不過,新版本的MySQL中,會將LRU插入操作從掃描時放到快取結束。

對在自己許可權範圍內的所有資料庫,每個RBU都有一個夜間備份。儘管有著天量級別的資料,Facebook的團隊還是可以在幾個小時內完成對所有資料的備份。

如果RBU失敗,自動化軟體會將其職責分配給同一叢集中其他系統。當它恢復上線後,職責會自動返回到最初的RBU主機。

Facebook團隊不會過分擔心單個系統的資料保留問題,因為他們有措施2。

措施2:Hadoop DFS

在每個備份和二進位制日誌收集完成後,他們會馬上將其複製到他們的大型定製化Hadoop叢集中。這些叢集是非常穩定的複製資料集,並有固定的保留時間。因為磁碟大小增長很快,較老的RBU可能不足以儲存一到兩天的備份。不過他們會按需要增長Hadoop叢集,同時不需要擔心底層硬體情況。Hadoop的分散式特性讓他們有足夠頻寬,完成快速資料恢復。

不久,他們會把非實時資料分析放到這些Hadoop叢集中。這可以降低資料庫中非關鍵讀的次數,讓Facebook網站的響應速度更快。

措施3:長期儲存

每週,他們會從Hadoop備份移動到另一個地區的分散儲存中。這些系統是最新而且安全的儲存系統,在他們的日常資料管理工具流程之外。

監控

除常用的系統監控外,他們還會捕捉很多特定的統計資料,比如binlog集合延遲、系統容量等等。

為備份失敗打分,是他們最有價值的工具。因為Facebook的資料庫和同時執行的維護任務量級,錯過某些備份也不奇怪。廣泛的失敗和多日沒有成功的單個備份,這都是他們要注意的重點。因此,某個錯過備份的得分會隨著時間呈指數級增長,這些得分的不同聚合,讓團隊能對備份的整體健康度有一個有效而快速的瞭解。

比如,在一天內,某個資料錯失一次備份,得1分,一天錯失50次備份,就是50分。但在三天內的一次資料庫錯失,就是27分(3的3次冪),三天內50次,這是很嚴重的問題,得分就是1350(50乘以3的3次冪)。這會在他們的監控圖上出現一個巨大的波峰,團隊會馬上對其採取行動。

恢復

在系統管理員中有句老話:“如果你沒有測試過你的備份,就等於沒有備份。”

因此,Facebook團隊構建了一個測試系統,會持續地從措施2開始,將資料恢復到測試伺服器上。恢復完成後,他們會執行多次資料完整性檢查。如果有任何反覆出現的問題,系統就會報警,提醒相關人員關注、稽核。該系統可以發現所有問題,包括MySQL的bug,到備份過程中的紕漏,並可以讓他們更靈活地應對備份環境中的變化。

他們構建了一個名為ORC(ORC恢復協調器的遞迴縮寫)的系統,工程師如何需要恢復他們所用工具的資料庫的過去版本,就可以以自服務方式使用該系統恢復資料。對於快速開發來說還是挺方便的。

在結尾,Eric Barrett說道:

備份不是最迷人的工程工作。它們即是技術活,又是重複性的,如果一切正常,沒人會注意。它們也是跨學科和團隊的,需要懂得系統、網路和軟體等多方面的專業知識。但是,確保你的記憶和聯絡安全無誤,這是無比重要的事情,而且到最後,也是充滿回報的事情。

有網友問到:

在不執行mysqld的RBU上,你們如何完成二進位制日誌的流傳送?什麼是模擬從程式?

Facebook的MySQL效能工程師Harrison Fisk給出了答案:

我們使用mysqlbinlog的–never–選項,並有一個用python開發的小包裝程式,會監控並保證mysqlbinlog執行成功。

來源:InfoQ-鄭柯 

Facebook如何實現PB級別資料庫自動化備份

相關文章