驗證(VERIFY) - 針對載入MySQL的數(shù)據(jù)執(zhí)行健康檢查(Sanity check)。
重播(REPLAY) - 如果有必要，在已還原備份的基礎(chǔ)上，下載二進(jìn)制日志備份并進(jìn)行事務(wù)重播。我們會使用 mysqlbinlog 程序篩選掉來自其他共置數(shù)據(jù)庫以及 空事務(wù) 的Binlog事件，隨后對同一個MySQL實例重播所需的事務(wù)。
每個步驟有自己對應(yīng)的失敗狀態(tài)，因此如果某個作業(yè)在 DOWNLOAD 步驟失敗，將顯示為 DOWNLOAD_FAILED 狀態(tài)，并且不會繼續(xù)進(jìn)入到 LOAD 步驟中。
Binlog的選擇邏輯
還原過程中最具挑戰(zhàn)的部分可能就是確定所要下載并重播的Binlog。完整和差異備份可以從主或從屬數(shù)據(jù)庫獲取，然而我們只從主數(shù)據(jù)庫創(chuàng)建Binlog備份。這意味著簡單的時間戳對比已經(jīng)無法用于確定要重播的Binlog。
我們于 2014年 在所有服務(wù)器上部署了 GTID ，因此每筆事務(wù)都可以獲得一個全局唯一標(biāo)識符。此外每臺運(yùn)行MySQL的服務(wù)器也維持了一個 gtid_executed (GTID集)變量，可將其作為對應(yīng)實例目前已執(zhí)行事務(wù)數(shù)量的計數(shù)器。
在具備GTID的情況下，從主數(shù)據(jù)庫重播至從屬數(shù)據(jù)庫的事務(wù)可以維持自己的GTID，這也意味著我們可以清楚地知道每筆事務(wù)是否包含在某個GTID集中。此外還可以針對服務(wù)器的 gtid_executed 值進(jìn)行超集/子集(Superset/subset)比較，因為該值實際上就是一種嚴(yán)格遞增的計數(shù)器和數(shù)學(xué)意義上的函數(shù)。
通過配合使用這些技術(shù)，即可在創(chuàng)建轉(zhuǎn)儲時記錄服務(wù)器的 gtid_executed 值，同時記錄每個Binlog文件中包含的GTID集，借此執(zhí)行一致的比較并確定Binlog中的哪些事務(wù)需要重播。此外一旦需要重播的第一筆事務(wù)確定后，無需重新對比其他GTID即可確定需要重播的所有后續(xù)事務(wù)。我們還會使用 mysqlbinlog 的 --stop-datetime 選項確定Binlog流要在何處停止。
結(jié)論
面對災(zāi)難性事件，備份是最后一重保障，備份的存在使得我們具備了更自信的故障恢復(fù)能力。然而僅僅創(chuàng)建備份是不夠的。ORC可以幫助我們對備份進(jìn)行持續(xù)不斷的測試，借此驗證備份的完整性，并讓我們更清楚地確定成功還原數(shù)據(jù)所需提供的資源。
以Facebook的規(guī)模，打造一個類似ORC這樣的系統(tǒng)還需要具備大量警報、監(jiān)控，以及自動化的失敗檢測和補(bǔ)救機(jī)制。這些功能均是通過CRT實現(xiàn)的，我們將通過另一篇文章介紹如何將這種還原過程擴(kuò)展至成千上萬個數(shù)據(jù)庫。
作者： Divij Rajkumar ， 閱讀英文原文 ： Continuous MySQL backup validation: Restoring backups