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

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

　　備份

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

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

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

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

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

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

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

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