連延遲從庫都用不上了，MySQL備份還能恢復嗎？

背景

首先交代一下背景，因爲某些因素的限制，咱們公司目前的備份策略採用的是隔天全備的方案，增量備份則使用的是binlog server的方式，那麼如何快速恢復就成爲了咱們須要思考的問題。mysql

正文

恢復需求

根據我以往的一些經驗來講，一般須要從備份恢復數據的場景有以下幾種：sql

被誤刪庫了；數據庫
被誤刪表了，類型爲TRUNCATE或者DROP；架構
被誤刪列了，類型爲ALTER ... DROP COLUMN；app
被誤刪數據了，類型爲DELETE或者UPDATE或者REPLACE；運維
表空間損壞或出現壞塊了。分佈式

根據場景來講，咱們能夠大體分爲兩類：工具

第一類爲不可逆恢復，也就是一般的DDL，好比上述的一、二、三、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的並行複製（假如你是5.6版本的話，因爲是基於database的並行複製，並不能使用到「並行」的特性），若是咱們能用到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 code tracer （ID ：mysqlcodetracer） dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱： editor@dbaplus.cn 背景

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

正文

恢復需求

根據我以往的一些經驗來講，一般須要從備份恢復數據的場景有以下幾種：

被誤刪庫了；
被誤刪表了，類型爲TRUNCATE或者DROP；
被誤刪列了，類型爲ALTER ... DROP COLUMN；
被誤刪數據了，類型爲DELETE或者UPDATE或者REPLACE；
表空間損壞或出現壞塊了。

根據場景來講，咱們能夠大體分爲兩類：

第一類爲不可逆恢復，也就是一般的DDL，好比上述的一、二、三、5等場景；

第二類爲可逆的恢復，一般能夠利用binlog進行回滾（要求binlog格式爲ROW，binlog_image爲FULL），也就是對應上述的場景4。