Facebook的MySQL數(shù)據(jù)庫，是世界上最龐大的MySQL數(shù)據(jù)庫之一，在不同地區(qū)有數(shù)千個數(shù)據(jù)庫服務(wù)器。因此，備份對他們來說是個巨大的挑戰(zhàn)。為了解決這個問題，他們構(gòu)建了一個高度自動化、非常有效的備份系統(tǒng)，每周移動多個PB的數(shù)據(jù)。Facebook數(shù)據(jù)團隊的Eric Barrett通過一篇文章分享了他們的做法。

他們沒有采用大量前載（front-loaded）測試，而是強調(diào)快速檢測失敗，并且進行快速、自動化糾正。部署幾百個數(shù)據(jù)庫服務(wù)器，只需很少人力干預(yù)。使用下面的三個措施，他們做到了有節(jié)奏的增長，同時具備支持上十億用戶的靈活性。

措施1：二進制日志和mysqldump

第一道防線稱為“措施1”，或“機架”備份（rack backup），簡稱RBU。在每個數(shù)據(jù)庫機架上，不論其類型為何，都有兩個RBU存儲服務(wù)器。以RBU作為數(shù)據(jù)庫服務(wù)器放在同一個機架中，這可以保證最大的帶寬和最小的延遲，它們同時可以作為緩存，在備份的下個措施使用。

收集二進制日志，是這些服務(wù)器的工作之一。二進制日志會不斷以流形式，通過模擬從進程（simulated slave process）輸送到RBU主機中。這樣一來，不需要運行mysqld，RBU就可以接收到同樣的更新作為復(fù)制版本。

在RBU上保存同步的二進制日志很重要：如果一個主數(shù)據(jù)庫服務(wù)器離線，該服務(wù)器上的用戶將無法更新狀態(tài)或是上傳照片。出現(xiàn)問題后，他們需要保證修復(fù)時間越短越好。有可用的二進制日志，就能讓他們在數(shù)秒內(nèi)啟動另一個數(shù)據(jù)庫作為主數(shù)據(jù)庫。由于RBU中有秒級的二進制日志，即使某個舊主數(shù)據(jù)庫完全不可用，也沒有關(guān)系，只要利用將記錄下的事務(wù)恢復(fù)到上一個備份中即可完成立即恢復(fù)。

RBU服務(wù)器的第二個工作是執(zhí)行傳統(tǒng)備份。MySQL備份有兩種方式：二進制和邏輯（mysqldump）。Facebook使用邏輯備份，因為它與版本無關(guān)，提供更好的數(shù)據(jù)完整性，更緊湊，恢復(fù)起來更省事。不過，當為某個數(shù)據(jù)庫構(gòu)建全新復(fù)制時，他們?nèi)匀皇褂枚M制拷貝。

mysqldump的一個主要好處是：磁盤上的數(shù)據(jù)損壞不會影響到備份中。如果磁盤某個扇區(qū)出現(xiàn)問題，或是寫入錯誤，InnoDB頁面校驗和就會出錯。在組合備份流時，MySQL會從內(nèi)存中讀取正確的內(nèi)容，或是去磁盤讀取，然后遇到錯誤的校驗和，停止備份（以及數(shù)據(jù)庫進程）。mysqldump的問題是：污染用來緩存InnoDB塊的LRU緩存。不過，新版本的MySQL中，會將LRU插入操作從掃描時放到緩存結(jié)束。

對在自己權(quán)限范圍內(nèi)的所有數(shù)據(jù)庫，每個RBU都有一個夜間備份。盡管有著天量級別的數(shù)據(jù)，F(xiàn)acebook的團隊還是可以在幾個小時內(nèi)完成對所有數(shù)據(jù)的備份。

如果RBU失敗，自動化軟件會將其職責(zé)分配給同一集群中其他系統(tǒng)。當它恢復(fù)上線后，職責(zé)會自動返回到最初的RBU主機。

Facebook團隊不會過分擔(dān)心單個系統(tǒng)的數(shù)據(jù)保留問題，因為他們有措施2。

措施2：Hadoop DFS

在每個備份和二進制日志收集完成后，他們會馬上將其復(fù)制到他們的大型定制化Hadoop集群中。這些集群是非常穩(wěn)定的復(fù)制數(shù)據(jù)集，并有固定的保留時間。因為磁盤大小增長很快，較老的RBU可能不足以保存一到兩天的備份。不過他們會按需要增長Hadoop集群，同時不需要擔(dān)心底層硬件情況。Hadoop的分布式特性讓他們有足夠帶寬，完成快速數(shù)據(jù)恢復(fù)。

不久，他們會把非實時數(shù)據(jù)分析放到這些Hadoop集群中。這可以降低數(shù)據(jù)庫中非關(guān)鍵讀的次數(shù)，讓Facebook網(wǎng)站的響應(yīng)速度更快。

措施3：長期存儲

每周，他們會從Hadoop備份移動到另一個地區(qū)的分散存儲中。這些系統(tǒng)是最新而且安全的存儲系統(tǒng)，在他們的日常數(shù)據(jù)管理工具流程之外。

監(jiān)控

除常用的系統(tǒng)監(jiān)控外，他們還會捕捉很多特定的統(tǒng)計數(shù)據(jù)，比如binlog集合延遲、系統(tǒng)容量等等。

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

比如，在一天內(nèi)，某個數(shù)據(jù)錯失一次備份，得1分，一天錯失50次備份，就是50分。但在三天內(nèi)的一次數(shù)據(jù)庫錯失，就是27分（3的3次冪），三天內(nèi)50次，這是很嚴重的問題，得分就是1350（50乘以3的3次冪）。這會在他們的監(jiān)控圖上出現(xiàn)一個巨大的波峰，團隊會馬上對其采取行動。

恢復(fù)

在系統(tǒng)管理員中有句老話：“如果你沒有測試過你的備份，就等于沒有備份。”

因此，F(xiàn)acebook團隊構(gòu)建了一個測試系統(tǒng)，會持續(xù)地從措施2開始，將數(shù)據(jù)恢復(fù)到測試服務(wù)器上?；謴?fù)完成后，他們會執(zhí)行多次數(shù)據(jù)完整性檢查。如果有任何反復(fù)出現(xiàn)的問題，系統(tǒng)就會報警，提醒相關(guān)人員關(guān)注、審核。該系統(tǒng)可以發(fā)現(xiàn)所有問題，包括MySQL的bug，到備份過程中的紕漏，并可以讓他們更靈活地應(yīng)對備份環(huán)境中的變化。

他們構(gòu)建了一個名為ORC（ORC恢復(fù)協(xié)調(diào)器的遞歸縮寫）的系統(tǒng)，工程師如何需要恢復(fù)他們所用工具的數(shù)據(jù)庫的過去版本，就可以以自服務(wù)方式使用該系統(tǒng)恢復(fù)數(shù)據(jù)。對于快速開發(fā)來說還是挺方便的。

在結(jié)尾，Eric Barrett說道：

有網(wǎng)友問到：

　　Facebook的MySQL性能工程師Harrison Fisk給出了答案：