MySQL備份恢復深度優化計劃 這是學習筆記的第 1800篇文章 備份恢復之前和同事投入了一些精力來完善，算是走上了平臺化對接的一個開始，在滿足功能的前提下，能夠基本實現數據全備，增備和DML閃回，但是在性能和可控性方面還是存在不少的改進之處，最近梳理了下已有的備份恢復策略，準備在這個方面能有一定的成績。 1.備份恢復技術選型 · 備份分為物理備份和邏輯備份，目前邏輯備份的使用存在問題，不夠靈活。 · 定制靈活的備份策略，數據量小（暫定小于10G）,使用邏輯備份+壓縮，其他使用物理備份。 · 邏輯備份備份表結構，需要完善表結構恢復步驟，后續可以補充數據生命周期管理，通過對比獲得數據屬性變化明細。 · 邏輯備份工具不局限于mysqldump,可以調研mydumper,充分測試，以提高性能為目標 2 備份恢復元數據 · 備份元信息和實例元信息需要統一存放; · 梳理目前遺漏的主從集群備份，為了減少主庫壓力，物理備份在從庫端完成 · 補充目前缺少的單點實例備份，目前暫定Infobright,TokuDB的從庫暫不使用物理備份，其他業務包括測試環境，大容量環境都需要做好數據備份。 · 補充完善數據恢復的元數據設計 · 接入備份配置時，可以根據歷史備份情況（比如時長，備份日志量）進行計算 3 MySQL備份流程 · 備份時間可以做到時間窗口統一調度 · binlog2sql的取binlog日志還需到線上分析無法從Binlog server中取出; · 梳理已有的binlog備份現狀，查漏補缺，思路和備份數據稽核一致，binlog備份在從庫端，需要充分利用binlog備份配置數據。 · 支持單庫單表備份 · 備份看板數據需要豐富 · Binlog和備份下沉至HDFS，和大數據對接兩個接口，一個是數據推送接口，一個是數據提取接口。 · Binlog備份需要定制和改進binlog2sql，目前的瓶頸在于python解析binlog效率較低，需要提高恢復效率 · Binlog2sql目前僅在mysql 5.7版本使用，需要補充適用在MySQL通用環境中 · 需要補充備份結果集的周期清理，通過靈活的配置來觸發。 4 MySQL恢復流程 · 恢復時間可用，保證根據數據量和日志量，恢復控制在1個小時以內; · 恢復的關鍵節點日志無法展示; · 異機恢復腳本無法做到完全可控，補齊binlog時時間過長，中間可能出現問題，還需要更靈活; · 恢復后數據庫需要手動修改配置才可上線，如GTID，bp size，serverid，主從同步自動搭建; · 數據恢復后加入MHA的考慮 · 對7天前數據恢復 · 恢復時長預測 · 異機恢復的文件只能選擇最近一個;