備份恢復(fù)，DBA最后一道防線，你完全掌握了嗎？

怎樣理解備份恢復(fù)

MySQL使用環(huán)境中，基本都會(huì)搭建高可用架構(gòu)最基本的主從，當(dāng)主庫(kù)發(fā)生故障導(dǎo)致無(wú)法使用的時(shí)，可以切換從節(jié)點(diǎn)提供服務(wù)。

那如果：

• 刪除操作:DROP TABLE操作 ，在Row模式下，可以通過binlog進(jìn)行恢復(fù),那再如果DROP DATABASE,那就無(wú)法恢復(fù)了。

• 在一次遷移升級(jí)過程中，bug導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法啟動(dòng)

• 需要找回前兩天的數(shù)據(jù)

• 云平臺(tái)全面癱瘓，雖然出現(xiàn)概率很小

這時(shí)可以通過之前備份+binglog進(jìn)行恢復(fù)數(shù)據(jù)。

備份的目的是發(fā)生災(zāi)難時(shí)進(jìn)行恢復(fù)。

這里提供幾個(gè)建議：

為了保證有效備份，需要考慮備份的擴(kuò)展性以及用于備份有效性驗(yàn)證的服務(wù)器，還需要配合多種備份機(jī)制

• 建設(shè)統(tǒng)一的備份服務(wù)器，備份服務(wù)器僅從本地機(jī)房實(shí)例進(jìn)行數(shù)據(jù)備份

• 備份異常時(shí)，需要有相應(yīng)的處理機(jī)制保障下一次備份能夠正常進(jìn)行

• 邏輯 物理備份 鏡像結(jié)合進(jìn)行備份

對(duì)于恢復(fù)，沒有恢復(fù)的備份是無(wú)意義的，

所以需要

• 建設(shè)統(tǒng)一的恢復(fù)驗(yàn)證服務(wù)器，用于定期驗(yàn)證備份有效性

• 通過定期恢復(fù)演練，確保備份的有效性

• 由于不可能所有備份都通過實(shí)際還原的方式進(jìn)行校驗(yàn)，使用文件MD5對(duì)比方式進(jìn)行每日基礎(chǔ)校驗(yàn)

備份恢復(fù)工具

MySQL方面各種備份手段：
備份恢復(fù)實(shí)現(xiàn)方式包含 物理 邏輯 商業(yè)軟件 虛擬機(jī)的整體備份。

常用的備份工具有三個(gè)：
邏輯導(dǎo)出：mysqldump，msyqlpump，mydumper
物理導(dǎo)出：xtrabackup。

1.mysqldump 是 MySQL 自帶的邏輯備份工具。
備份原理是通過協(xié)議連接到 MySQL 數(shù)據(jù)庫(kù)，將需要備份的數(shù)據(jù)查詢出來(lái)，將查詢出的數(shù)據(jù)轉(zhuǎn)換成對(duì)應(yīng)的SQL語(yǔ)句，當(dāng)需要還原這些數(shù)據(jù)時(shí)，只要執(zhí)行這些SQL語(yǔ)句，即可將對(duì)應(yīng)的數(shù)據(jù)還原。

2.xtrabackup是一款mysql開源備份(物理備份)工具，是由percona公司開發(fā)的。

3.mydumper是一個(gè)針對(duì)MySQL和Drizzle的高性能多線程備份和恢復(fù)工具，能多線程進(jìn)行備份。

1.數(shù)據(jù)量少于10G以內(nèi)使用mydumper,mysqldump 進(jìn)行備份，其他備份建議xtrabackup
2.除了以上場(chǎng)景單表備份，表結(jié)構(gòu)等導(dǎo)出的時(shí)候，建議使用邏輯導(dǎo)出。
3.mysqldump是單線程 mydumper是多線程，性能來(lái)說mydumper更優(yōu)。
性能方面：mysqlpump>mydumper>mysqldump 但mysqlpump存在一些bug

4.處置之外MySQL8.0的clone功能確實(shí)非常不錯(cuò)的功能，需要腳本配合，應(yīng)該比xtrabackup優(yōu)秀，就是業(yè)界使用經(jīng)驗(yàn)太少，后期繼續(xù)關(guān)注

備份策略:

對(duì)于不同的數(shù)據(jù)，可以采取不同的備份策略，結(jié)合全備和增量備份的方式，binlog也需要定期進(jìn)行備份

以下是常用備份策略：

備份方面最佳實(shí)踐:

• 使用xtrabackup進(jìn)行物理備份

• 使用mydumper進(jìn)行邏輯備份（支持并行邏輯備份恢復(fù)）

• 備份文件存儲(chǔ)本地 或則 介質(zhì)為NFS

• 使用binlog2sql進(jìn)行閃回恢復(fù).

• 對(duì)于重要系統(tǒng)，可以使用延遲從庫(kù)進(jìn)行備份恢復(fù)
  

• 條件允許，系統(tǒng)級(jí)別每天額外每天進(jìn)行鏡像備份，之后再做去重處理。

備份恢復(fù)注意

常見的備份失敗問題：

生產(chǎn)案例：

1. xtrabackup備份和恢復(fù)的GTID不一致：5.7和8.0都會(huì)存在

• 備份恢復(fù)的實(shí)例顯示已執(zhí)行過的 GTID xtrabackup_binlog_info 文件記錄的信息是 1-9969，
  而備份文件顯示的是 1-473

• 將該備份恢復(fù)至一個(gè)新實(shí)例并啟動(dòng)該實(shí)例，執(zhí)行 show master status; 查看信息：
  

• 分析
  xtrabackup_binlog_info 文件中信息是有兩種情況獲取：全局系統(tǒng)變量 gtid_exected 或則 mysql.gtid_executed
  這部分有興趣的技術(shù)同仁，可以深入研究。

解決方案：
備份前 FLUSH ?LOGS；之后通過show master 和 select * from mysql.gtid_executed; 確認(rèn)gtid 是否一致。
也可以忽略掉, 通過GTID_PURGED方式處理

2. sql導(dǎo)致失敗的案例

• 堵塞語(yǔ)句kill（從開始執(zhí)行FLUSH TABLES WITH READ LOCK):kill-long-query-type ，kill-long-queries-timeout

• 長(zhǎng)查詢的語(yǔ)句：ftwrl-wait-query-type ，ftwrl-wait-timeout ，ftwrl-wait-threshold

• no-lock：表示關(guān)閉FTWRL的表鎖

3. DDL語(yǔ)句導(dǎo)致失敗案例

InnoDB: Last flushed lsn: 3375345258517 load_index lsn 3379255303757InnoDB: An optimized (without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet. PXB will not be able take a consistent backup. Retry the backup operation

xtrabackup在備份innoDB數(shù)據(jù)是，有2種線程：
redo拷貝線程和ibd數(shù)據(jù)拷貝線程。
xtrabackup進(jìn)程開始執(zhí)行后，會(huì)啟動(dòng)一個(gè)redo拷貝的線程，用于從最新的checkpoint點(diǎn)開始順序拷貝redo.log；再啟動(dòng)ibd數(shù)據(jù)拷貝線程，進(jìn)行拷貝ibd數(shù)據(jù)。
但導(dǎo)致刷新redo 丟失的情況下，那備份就會(huì)失敗

刷新大量數(shù)據(jù)，或則 redo刷新跟不上
導(dǎo)致刷新redo丟失的情況下，那備份就會(huì)失敗

4. 大量事務(wù)刷新日志&IO性能差

xtrabackup: error: log block numbers mismatch:xtrabackup: error: expected log block no. 201901064, but got no. 208192508 from the log file.xtrabackup: error: it looks like InnoDB log has wrapped around before xtrabackup could process all records due to either log copying being too slow, or  log files being too small.xtrabackup: Error: xtrabackup_copy_logfile() failed.

Innodb產(chǎn)生日志的速度遠(yuǎn)超于Xtrabackup復(fù)制的速度，部分Innodb日志被截?cái)啵?br>
導(dǎo)致備份失敗。

5. 空間不足

innobackupex: Error writing file '/tmp/xbtempevLQbf' (Errcode: 28 - No space left on device)xtrabackup: Error: write to logfile failedxtrabackup: Error: xtrabackup_copy_logfile() failed.

所以備份的時(shí)候需要確認(rèn)空間，mysql的tmp空間

6. 備份軟件，處理機(jī)制不太友好
備份日志里已經(jīng)報(bào)出錯(cuò)誤，但xtrabackup線程一直存在。

failed to execute query SET SESSION lock_wait_timeout=31536000,MySQL server has gone away.

MySQL報(bào)gone away錯(cuò)誤的常見因素
1、MySQL連接超時(shí)(受參數(shù)wait_timeout和interactive_timeout控制)
2、MySQL連接被KILL
3、MySQL實(shí)例重啟

7. nfs掛載注意

從數(shù)據(jù)庫(kù)服務(wù)器備份到NFS掛載，然后使用另一臺(tái)同樣掛載該卷的服務(wù)器來(lái)準(zhǔn)備備份(應(yīng)用日志)，那么其他服務(wù)器對(duì)數(shù)據(jù)的視圖可能不一致。這是因?yàn)閿?shù)據(jù)可能還沒有被刷新到NFS服務(wù)器——它可能就在數(shù)據(jù)庫(kù)服務(wù)器的緩存中。
https://www.percona.com/blog/2010/12/09/using-xtrabackup-on-nfs-for-mysql-backups/

8. 恢復(fù)注意

• mysql數(shù)據(jù)目錄賦予權(quán)限

• 必須清除原先的data目錄和binglog信息，不清楚會(huì)導(dǎo)致無(wú)法正常啟動(dòng) 或則 啟動(dòng)之后的binlog和gtid不一致問題

總結(jié)

• 日常工作中數(shù)據(jù)備份是非常重要的，操作前做好備份，當(dāng)碰到問題點(diǎn)的時(shí)候，能給你帶來(lái)意想不到的便利。

• 不要懶惰，通過提供的平臺(tái)有效的利用多種備份手段，也非常重要