背景

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

恢復(fù)需求

根據(jù)我以往的一些經(jīng)驗來說，通常需要從備份恢復(fù)數(shù)據(jù)的場景有如下幾種：

1.被誤刪庫了

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

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

4.被誤刪數(shù)據(jù)了，類型為DELETE或者UPDATE或者REPLACE

5.表空間損壞或出現(xiàn)壞塊了

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

• 第一類為不可逆恢復(fù)，也就是通常的DDL，比如上述的1、2、3、5等場景
• 第二類為可逆的恢復(fù)，通?？梢岳胋inlog進(jìn)行回滾（要求binlog格式為ROW，binlog_image為FULL），也就是對應(yīng)上述的場景4
  

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

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

全備恢復(fù)（異機恢復(fù)）

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

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

增備恢復(fù)

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

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

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

增備恢復(fù)優(yōu)化

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

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

master上binlog恢復(fù)

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

binlogserver上binlog恢復(fù)

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

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

優(yōu)化后的恢復(fù)流程

經(jīng)過優(yōu)化以后，我們的增備恢復(fù)流程就變成了，首先通過master上的binlog進(jìn)行恢復(fù)，如果發(fā)現(xiàn)master上的binlog已經(jīng)被purge了，那么通過binlogserver上的binlog進(jìn)行恢復(fù)，這樣一來我認(rèn)為是比較科學(xué)合理的恢復(fù)流程。

各種恢復(fù)方式時效性對比

業(yè)務(wù)恢復(fù)

到這里，我們已經(jīng)完成了全量+增量的備份數(shù)據(jù)恢復(fù)，這個時候需要同研發(fā)確認(rèn)數(shù)據(jù)，確認(rèn)完成以后將對應(yīng)的表恢復(fù)到原先的master，通常采用的方式有：

1. mysqldump導(dǎo)出+導(dǎo)入目標(biāo)實例
2. 表空間傳輸
   

總結(jié)

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

最后還是提醒幾點：

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

以上就是MySQL備份恢復(fù)設(shè)計思路的詳細(xì)內(nèi)容，更多關(guān)于MySQL備份恢復(fù)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論