Facebook 備份 MySQL 資料並且確認正確性的方法

Facebook 再多花了一些篇幅數對於 MySQL 資料備份以及確認正確性的方法:「Continuous MySQL backup validation: Restoring backups」。

首先是 Continuous Restore Tier (CRT) 這塊,可以看到他們在這塊很仰賴 HDFS 當作備份的第一層基地,包括了 Full logical backups (用 mysqldump)、Differential (diff) backups 以及 Binary log (binlog) backups (stream 進 HDFS)。

另外上了 GTID,對於後續的處理會比較方便:

All of our database servers also use global transaction IDs (GTIDs), which gives us another layer of control when replaying transactions from binlog backups.

在 CRT 這塊可以看到其實是拿現成的工具堆起來,不同單位會因為規模而有不同的作法。真正的重點反而在 ORC Restore Coordinator (ORC) 這塊,可以看到 Facebook 開發了大量的程式將回復這件事情自動化處理:

在收到回復的需求後,可以看到 Peon 會從 HDFS 拉資料出來,並且用 binlog replay 回去:

Peons contain all relevant logic for retrieving backups from HDFS, loading them into their local MySQL instance, and rolling them forward to a certain point in time by replaying binlogs. Each restore job a peon works on goes through these five stages[.]

也是因為 Facebook 對 MySQL 的用量大到需要自動化這些事情,才有這些東西...

Amazon S3 與 HDFS 的速度差異

作者繼續以 A Billion Taxi Rides 的資料測試各種差異,這次測了 Amazon S3HDFS 的速度差異:「A Billion Taxi Rides: AWS S3 versus HDFS」。

前半部都在說明測試的環境設定,重點在文章的最後面 (也就是「Benchmarking HDFS」這段),裡面有各種 query 的速度。HDFS 的速度大約是 Amazon S3 的 1.25 到 1.75 倍,作者給的結論是:

Though the speed improvements using HDFS are considerable, S3 did perform pretty well. At worst there's a 1.75x overhead in exchange for virtually unlimited scalability, 11 9's of durability and no worrying about over/under-provisioning storage space.

雖然 HDFS 比較快,但 Amazon S3 其實表現的不錯,另外資料安全性 (平均 99.999999999%,也就是 11 個 9 的 durability) 及不需要怕空間不夠的優點也是應該考慮進去的因素。

HDFS 上的 Memory Storage

Apache Spark 以記憶體操作為賣點的想法,有人提出來直接讓 HDFS 支援 Memory Storage 了:「Discardable Distributed Memory: Supporting Memory Storage in HDFS」,文章的副標題「HDFS's storage subsystem gets a boost with discardable distributed memory」也說明了特性。

整個計畫在「[HDFS-5851] Support memory as a storage medium - ASF JIRA」這邊可以看到。

不過 Spark 帶來的想法現在才有進度... 這發展的速度也太快了 XD