背景

首先交代一下背景，由于某些因素的限制，我們公司目前的備份策略采用的是隔天全備的方案，增量備份則使用的是binlog server的方式，那么如何快速恢復就成為了我們需要思考的問題

恢復需求

根據我以往的一些經驗來說，通常需要從備份恢復數據的場景有如下幾種：

1.被誤刪庫了

2.被誤刪表了，類型為TRUNCATE或者DROP

3.被誤刪列了，類型為ALTER ... DROP COLUMN

4.被誤刪數據了，類型為DELETE或者UPDATE或者REPLACE

5.表空間損壞或出現壞塊了

根據場景來說，我們可以大致分為兩類：

• 第一類為不可逆恢復，也就是通常的DDL，比如上述的1、2、3、5等場景
• 第二類為可逆的恢復，通常可以利用binlog進行回滾（要求binlog格式為ROW，binlog_image為FULL），也就是對應上述的場景4
  

對于第二類的恢復需求一般來說都比較容易處理，可以利用binlog回滾工具，例如業界比較著名的有binlog2sql以及MyFlash等，這里暫不贅述，我們重點來討論第一類需求。

為了達到快速恢復的目的，業界DBA經常會采用的方式就是部署一個延遲從庫來解決，我們公司目前 所有的核心DB都部署了延遲從庫。但是即便有了延遲從庫，假設我們錯過了延遲的時間，或者在后續利用延遲從庫恢復的時候指定錯了位點，導致了誤刪DDL同樣應用到了從庫，這個時候我們就沒有辦法利用延遲從庫這根救命稻草了。

全備恢復（異機恢復）

此時，我們只能通過備份來進行數據恢復了。首先我們需要恢復全備，通常來說就是xtrabackup備份的物理備份了。假設你的備份在遠程的機器上，那么你可能需要做如下幾步動作來進行全備恢復：

1. 將備份scp或者rsync到目標實例機器上
2. 假設備份文件是壓縮的情況下，需要解壓
3. 解壓完成后，需要apply redo log
4. 更改文件權限
5. 假設你直接將文件拷貝到的目標實例的datadir目錄下，那么這一步你就可以直接啟動mysqld，假設不是，那么你還需要將數據文件move-back或者copy-back到目標實例的datadir
6. 實例啟動
   

增備恢復

到這里，全備已經恢復完成了，接下來需要做的就是增量恢復了。按照我們之前的備份方案，我們需要通過binlog來完成增量數據的恢復。對于binlog恢復，我們通常需要以下幾個步驟

1. 確定全備對應的binlog位點，也就是需要恢復的起始點
2. 解析主庫的binlog，確定誤刪數據的位點，作為我們恢復的終點
3. 利用mysqlbinlog —start-position —stop-position+管道的方式，將binlog恢復到目標實例上

binlog恢復的方式有很多種，你可以用的是原先master上的binlog，也可以用binlogserver上的binlog，需要做的就是找到binlog恢復的終點即可。

增備恢復優化

到這里，你可能會覺得，利用binlog恢復有點麻煩。確實是這樣的，利用mysqlbinlog命令并沒有辦法指定恢復到哪個GTID，只能通過解析binlog，找到需要恢復到的GTID對應的pos位點才行，這對于自動化來說實現起來會比較麻煩。另外，如果利用mysqlbinlog命令恢復，屬于單線程恢復，假設需要恢復的binlog量比較多的話，那么這個增量恢復的時間可想而知。

那么有什么辦法能加速binlog應用呢？這里我們就想到了MySQL5.7的并行復制，如果我們能用到sql thread的并行復制，是不是這個問題就解決了呢？

master上binlog恢復

我們回到全備恢復的位點，我們將新實例作為原先的master的slave，然后恢復到指定的GTID位置就可以了呢？沒錯，這是一種非常簡便又輕松還不容易出錯的方式，并且還可以利用并行復制的原理來加速binlog應用的目的。但是這種方式的一個要求就是原先的master最老的binlog包含了我們需要的起始恢復位點，這個很容易想到，所以，這將成為我們首選的恢復方式。

binlogserver上binlog恢復

假設原先master上的binlog已經被purge了，那么我們那需要從binlog上去恢復。有人可能會想到將binlogserver上的binlog拷貝到原先的master上，然后通過修改binlog index來達到注冊的目的，實際上這并不可取，具體原因可以見《手動注冊binlog文件造成主從異常》。

我們可以采取的方式是什么呢？就是利用binlogserver做成偽裝master，然后將從庫change上去，其思想就是欺騙slave，讓slave的io_thread將缺失的binlog拉取過來，sql_thread并行應用binlog event（我們將在下一節具體演示這種方式）。

優化后的恢復流程

經過優化以后，我們的增備恢復流程就變成了，首先通過master上的binlog進行恢復，如果發現master上的binlog已經被purge了，那么通過binlogserver上的binlog進行恢復，這樣一來我認為是比較科學合理的恢復流程。

各種恢復方式時效性對比

業務恢復

到這里，我們已經完成了全量+增量的備份數據恢復，這個時候需要同研發確認數據，確認完成以后將對應的表恢復到原先的master，通常采用的方式有：

1. mysqldump導出+導入目標實例
2. 表空間傳輸
   

總結

本節主要介紹了備份恢復的設計流程，在我們沒有辦法優化全備恢復的情況下，我們通過優化增量備份方式和流程達到縮短恢復時間的目的。并且需要說明的一點是，本節介紹的目前我還沒有完全測試，不保證每個點都是正確的，還需要進一步驗證，驗證通過以后我也會通知大家，并且結合到現有的數據庫運維平臺，做到自動化恢復

最后還是提醒幾點：

1. 數據是無形的財產，請廣大DBA朋友務必做好備份并做好備份驗證
2. 如果有條件的情況下，盡量部署延遲從庫
3. 做好恢復預案，免得恢復的時候手忙腳亂，菊花打緊
4. 根據場景選擇合適的恢復手段，盡量縮短恢復時間

以上就是MySQL備份恢復設計思路的詳細內容，更多關于MySQL備份恢復的資料請關注腳本之家其它相關文章！