MySQL備份恢復設計思路
背景
首先交代一下背景，由於某些因素的限制，我們公司目前的備份策略採用的是隔天全備的方案，增量備份則使用的是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備份的物理備份了。假設你的備份在遠端的機器上，那麼你可能需要做如下幾步動作來進行全備恢復：
- 將備份scp或者rsync到目標例項機器上
- 假裝置份檔案是壓縮的情況下，需要解壓
- 解壓完成後，需要apply redo log
- 更改檔案許可權
- 假設你直接將檔案拷貝到的目標例項的datadir目錄下，那麼這一步你就可以直接啟動mysqld，假設不是，那麼你還需要將資料檔案move-back或者copy-back到目標例項的datadir
- 例項啟動
增備恢復
到這裡，全備已經恢復完成了，接下來需要做的就是增量恢復了。按照我們之前的備份方案，我們需要通過binlog來完成增量資料的恢復。對於binlog恢復，我們通常需要以下幾個步驟
- 確定全備對應的binlog位點，也就是需要恢復的起始點
- 解析主庫的binlog，確定誤刪資料的位點，作為我們恢復的終點
- 利用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，通常採用的方式有：
- mysqldump匯出+匯入目標例項
- 表空間傳輸
總結
本節主要介紹了備份恢復的設計流程，在我們沒有辦法優化全備恢復的情況下，我們通過優化增量備份方式和流程達到縮短恢復時間的目的。並且需要說明的一點是，本節介紹的目前我還沒有完全測試，不保證每個點都是正確的，還需要進一步驗證，驗證通過以後我也會通知大家，並且結合到現有的資料庫運維平臺，做到自動化恢復
最後還是提醒幾點：
- 資料是無形的財產，請廣大DBA朋友務必做好備份並做好備份驗證
- 如果有條件的情況下，儘量部署延遲從庫
- 做好恢復預案，免得恢復的時候手忙腳亂，菊花打緊
- 根據場景選擇合適的恢復手段，儘量縮短恢復時間
以上就是MySQL備份恢復設計思路的詳細內容，更多關於MySQL備份恢復的資料請關注我們其它相關文章！