背景

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

恢復(fù)需求

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

1.被誤刪庫了

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

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

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

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

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

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

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

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

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

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

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

增備恢復(fù)

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

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

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

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

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

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

master上binlog恢復(fù)

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

binlogserver上binlog恢復(fù)

假設(shè)原先master上的binlog已經(jīng)被purge了，那么我們那需要從binlog上去恢復(fù)。有人可能會(huì)想到將binlogserver上的binlog拷貝到原先的master上，然后通過修改binlog index來達(dá)到注冊(cè)的目的，實(shí)際上這并不可取，具體原因可以見《手動(dòng)注冊(cè)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ù)方式時(shí)效性對(duì)比

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

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

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

總結(jié)

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

最后還是提醒幾點(diǎn)：

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

以上就是MySQL備份恢復(fù)設(shè)計(jì)思路的詳細(xì)內(nèi)容，更多關(guān)于MySQL備份恢復(fù)的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！