MySQL對于GitHub的重要性不言而喻，本文作者從MySQL的備份、自動測試能否成功從備份恢復(fù)數(shù)據(jù)、模擬各種 master 可能掛掉的情況、自動測試 failover 是否正常、自動測試 schema 遷移等幾個方面說明了為何會相信MySQL自動化。以下為譯文。

　　對于GitHub來說，MySQL的基礎(chǔ)架構(gòu)是非常重要的組件。MySQL給GitHub.com、GitHub的API、身份驗證等提供服務(wù)。每個git請求都或多或少會接觸到MySQL。我們的任務(wù)是保持?jǐn)?shù)據(jù)的可用性和完整性。即使MySQL集群服務(wù)出現(xiàn)意外了，也需要能夠執(zhí)行一些任務(wù)，比如繁重的清理工作、臨時更新、在線模式遷移、集群拓撲重構(gòu)、池化和負載平衡等等。我們有基礎(chǔ)設(shè)施來自動化這些操作。在本文將分享一些例子，說明如何通過持續(xù)測試來建立我們對基礎(chǔ)設(shè)施的信任。

　　備份

　　對數(shù)據(jù)進行備份是非常重要的。如果還沒有進行備份，那么這就是一個潛在的問題。Percona Xtrabackup是用來為MySQL數(shù)據(jù)庫提供完整備份的工具。如果有一些已經(jīng)確定需要保存的數(shù)據(jù)，也有一個專門備份數(shù)據(jù)的服務(wù)器。

　　除了完整的二進制備份之外，每天還運行幾次邏輯備份。這些備份使工程師能夠獲得最新的數(shù)據(jù)。有時，他們希望從表中獲得一組完整的數(shù)據(jù)，這樣他們就可以在跟生產(chǎn)數(shù)據(jù)量一樣的表上測試索引的更改是否有效，或者從某個時間點查看數(shù)據(jù)。Hubot允許恢復(fù)一張備份的表，當(dāng)表已經(jīng)導(dǎo)入好以后，它就會ping給我們。

　　數(shù)據(jù)被加載到非生產(chǎn)數(shù)據(jù)庫，該數(shù)據(jù)庫可供那些提出恢復(fù)數(shù)據(jù)要求的工程師們訪問。

　　最后一種進行數(shù)據(jù)備份的方法是使用延時復(fù)制。與其說是一種備份，倒不如說是對數(shù)據(jù)的一種保障。對于每個生產(chǎn)集群，有一個延遲4小時復(fù)制的主機。假如某個查詢沒有運行，我們會在chatops（即一種會話驅(qū)動型開發(fā)的做法）上運行mysql panic。這將導(dǎo)致所有的延遲復(fù)制立即停止復(fù)制，然后“呼叫”數(shù)據(jù)庫管理員。

　　這樣就可以使用延遲復(fù)制來驗證是否存在問題，然后將二進制日志快速轉(zhuǎn)發(fā)到發(fā)生錯誤之前的位置。然后，我們可以將那個點之前的數(shù)據(jù)恢復(fù)到主服務(wù)器。

　　雖然說備份這個功能設(shè)計的很棒，但是如果一些未知或未捕獲的錯誤導(dǎo)致備份沒有成功，它們就會變得毫無價值。使用腳本恢復(fù)備份的好處就是它允許我們通過cron（是一個linux下的定時執(zhí)行工具，可以在無需人工干預(yù)的情況下運行作業(yè)）自動驗證備份文件是否有效。我們?yōu)槊總€集群都設(shè)置了一臺專用主機，這臺主機就是用來恢復(fù)最新的備份數(shù)據(jù)。這樣可以確保備份正常運行，并且我們能夠從備份中檢索數(shù)據(jù)。

　　根據(jù)數(shù)據(jù)集大小會選擇每天進行幾次恢復(fù)。恢復(fù)后的服務(wù)器會按照預(yù)期加入到復(fù)制流中，并能夠趕上復(fù)制。這種做法不僅僅是在測試備份文件是否可恢復(fù)，而且還可以測試需要識別的時間點是否準(zhǔn)確。如果恢復(fù)過程中出現(xiàn)問題，我們會收到通知。

　　還追蹤恢復(fù)的時間，所以我們很清楚在緊急情況下建立新的副本或恢復(fù)需要多長時間。