墨墨導讀：備份恢復是DBA最後一道防線。最近項目碰到備份恢復的相關的事項，結合自己的經驗，鞏固一下知識。
怎樣理解備份恢復
MySQL使用環境中，基本都會搭建高可用架構最基本的主從，當主庫發生故障導致無法使用的時，可以切換從節點提供服務。
那如果：
刪除操作:DROP TABLE操作 ，在Row模式下，可以通過binlog進行恢復,那再如果DROP DATABASE,那就無法恢復了。
在一次遷移升級過程中，bug導致資料庫無法啟動
需要找回前兩天的數據
雲平臺全面癱瘓，雖然出現概率很小
這時可以通過之前備份+binglog進行恢復數據。
備份的目的是發生災難時進行恢復。
這裡提供幾個建議：
為了保證有效備份，需要考慮備份的擴展性以及用於備份有效性驗證的伺服器，還需要配合多種備份機制
建設統一的備份伺服器，備份伺服器僅從本地機房實例進行數據備份
備份異常時，需要有相應的處理機制保障下一次備份能夠正常進行
邏輯 物理備份 鏡像結合進行備份
對於恢復，沒有恢復的備份是無意義的，
所以需要
建設統一的恢復驗證伺服器，用於定期驗證備份有效性
通過定期恢復演練，確保備份的有效性
由於不可能所有備份都通過實際還原的方式進行校驗，使用文件MD5對比方式進行每日基礎校驗
備份恢復工具
MySQL方面各種備份手段：
備份恢復實現方式包含 物理 邏輯 商業軟體 虛擬機的整體備份。
常用的備份工具有三個：
邏輯導出：mysqldump，msyqlpump，mydumper
物理導出：xtrabackup。
1.mysqldump 是 MySQL 自帶的邏輯備份工具。
備份原理是通過協議連接到 MySQL 資料庫，將需要備份的數據查詢出來，將查詢出的數據轉換成對應的SQL語句，當需要還原這些數據時，只要執行這些SQL語句，即可將對應的數據還原。
2.xtrabackup是一款mysql開源備份(物理備份)工具，是由percona公司開發的。
3.mydumper是一個針對MySQL和Drizzle的高性能多線程備份和恢復工具，能多線程進行備份。
1.數據量少於10G以內使用mydumper,mysqldump 進行備份，其他備份建議xtrabackup
2.除了以上場景單表備份，表結構等導出的時候，建議使用邏輯導出。
3.mysqldump是單線程 mydumper是多線程，性能來說mydumper更優。
性能方面：mysqlpump>mydumper>mysqldump 但mysqlpump存在一些bug
4.處置之外MySQL8.0的clone功能確實非常不錯的功能，需要腳本配合，應該比xtrabackup優秀，就是業界使用經驗太少，後期繼續關注
備份策略:
對於不同的數據，可以採取不同的備份策略，結合全備和增量備份的方式，binlog也需要定期進行備份
以下是常用備份策略：
備份方面最佳實踐:
使用xtrabackup進行物理備份
使用mydumper進行邏輯備份（支持並行邏輯備份恢復）
備份文件存儲本地 或則 介質為NFS
使用binlog2sql進行閃回恢復.
對於重要系統，可以使用延遲從庫進行備份恢復
條件允許，系統級別每天額外每天進行鏡像備份，之後再做去重處理。
備份恢復注意
常見的備份失敗問題：
生產案例：
1.xtrabackup備份和恢復的GTID不一致：5.7和8.0都會存在
備份恢復的實例顯示已執行過的 GTID xtrabackup_binlog_info 文件記錄的信息是 1-9969，
而備份文件顯示的是 1-473
將該備份恢復至一個新實例並啟動該實例，執行 show master status; 查看信息：
分析
xtrabackup_binlog_info 文件中信息是有兩種情況獲取：全局系統變量 gtid_exected 或則 mysql.gtid_executed
這部分有興趣的技術同仁，可以深入研究。
解決方案：
備份前 FLUSH LOGS；之後通過show master 和 select * from mysql.gtid_executed; 確認gtid 是否一致。
也可以忽略掉, 通過GTID_PURGED方式處理
2.sql導致失敗的案例
堵塞語句kill（從開始執行FLUSH TABLES WITH READ LOCK):kill-long-query-type ，kill-long-queries-timeout
長查詢的語句：ftwrl-wait-query-type ，ftwrl-wait-timeout ，ftwrl-wait-threshold
no-lock：表示關閉FTWRL的表鎖
3.DDL語句導致失敗案例
xtrabackup在備份innoDB數據是，有2種線程：
redo拷貝線程和ibd數據拷貝線程。
xtrabackup進程開始執行後，會啟動一個redo拷貝的線程，用於從最新的checkpoint點開始順序拷貝redo.log；再啟動ibd數據拷貝線程，進行拷貝ibd數據。
但導致刷新redo 丟失的情況下，那備份就會失敗
刷新大量數據，或則 redo刷新跟不上
導致刷新redo丟失的情況下，那備份就會失敗
4.大量事務刷新日誌&IO性能差
Innodb產生日誌的速度遠超於Xtrabackup複製的速度，部分Innodb日誌被截斷，
導致備份失敗。
5.空間不足
所以備份的時候需要確認空間，mysql的tmp空間
6.備份軟體，處理機制不太友好
備份日誌裡已經報出錯誤，但xtrabackup線程一直存在。
MySQL報gone away錯誤的常見因素
1、MySQL連接超時(受參數wait_timeout和interactive_timeout控制)
2、MySQL連接被KILL
3、MySQL實例重啟
7.nfs掛載注意
從資料庫伺服器備份到NFS掛載，然後使用另一臺同樣掛載該卷的伺服器來準備備份(應用日誌)，那麼其他伺服器對數據的視圖可能不一致。這是因為數據可能還沒有被刷新到NFS伺服器——它可能就在資料庫伺服器的緩存中。
https://www.percona.com/blog/2010/12/09/using-xtrabackup-on-nfs-for-mysql-backups/
8.恢復注意
mysql數據目錄賦予權限
必須清除原先的data目錄和binglog信息，不清楚會導致無法正常啟動 或則 啟動之後的binlog和gtid不一致問題
總結
日常工作中數據備份是非常重要的，操作前做好備份，當碰到問題點的時候，能給你帶來意想不到的便利。
不要懶惰，通過提供的平臺有效的利用多種備份手段，也非常重要