Mysql實時備份實現方法？

數據備份是數據容災的最后一道防線。即使是兩地三中心的架構，備份依然重要。如果備份出現問題，備份過程中交易業務會受到影響，備份數據無法恢復，這也是企業無法承受的。因此，選擇合適的備份工具尤為重要。

每個企業數據庫都有自己的備份工具。MEB(MySQL企業備份)是MySQL企業版中最重要的工具之一，是面向企業客戶的數據備份方案。

Xtrabackup一直作為MEB的開源備胎存在，從MySQL8.0開始情況可能會有所不同。

由于MySQL8.0的新功能，如備份鎖、重做日志歸檔和頁面跟蹤，MEB備份/恢復體驗將會更好。目前xtrabackup還不支持這些功能。

MySQL企業版還有哪些功能？

功能1:備份鎖

在8.0之前，xtrabackup或MEB用于物理備份。為了確保備份期間InnoDB引擎表與其他引擎數據文件和binlog日志的一致性，我們設置了一個全局讀鎖，然后復制非InnoDB文件。在此期間，MySQL將變為只讀，數據無法寫入。桌子越多，花費的時間就越長。如果在沒有rsync參數的情況下使用xtrabackup，frm文件會被一個一個的復制，加鎖時間會更長，對業務影響很大。

我曾經遇到過在一個虛擬機中部署超過12，000個表的情況。當時用的是xtrabackup，備份腳本被鎖了十幾分鐘，但是MEB沒有這樣的問題。

MySQL8.0支持輕量級備份鎖lock實例進行備份，數據字典由InnoDB重構存儲。如果沒有創建非InnoDB表，MEB會默認使用備份鎖獲取binlog日志的一致性位置，阻止DDL操作，但不會影響DML操作。

只有InnoDB表，只有備份鎖。

如果有一個非InnoDB表，請將其全局鎖定。

功能2:重做日志歸檔

MEB可以做在線熱備，備份時不影響數據庫讀寫。這樣使用InnoDB事務日志在備份過程中持續監控重做日志的變化，讀取增量變化，寫入ibbackup_logfile，這樣就不需要鎖定，保證備份的一致性。(非InnoDB文件需要讀鎖定副本)

如果備份時數據庫寫負載特別重，而ibbackup_logfile寫速度慢，重做日志大小不大，就很有可能出現。ibbackup_logfilecan跟不上重做日志記錄的生成速度。如果重做日志空間不夠，日志文件需要被覆蓋，所以可以t寫入ibbackup_logfile將會丟失，導致備份失敗。

MEB4.1對此進行了優化，將重做日志的處理線程拆分成多線程進行協作，提高了處理重做日志的效率，降低了重做日志覆蓋導致備份失敗的概率。但是重做日志的添加速度和ibbackup_logfile的寫入速度差距太大，問題還是會出現。

MySQL8.0.17支持重做日志歸檔，徹底解決了這個問題。備份前，設置innodb_redo_log_archive_dirs，并指定重做日志歸檔目錄。備份MEB時，會自動啟動日志歸檔，檢查點時會將舊記錄歸檔到該目錄，然后從歸檔文件中讀取重做日志記錄，從而避免可能因覆蓋而導致的重做記錄丟失。

注意:innodb_redo_log_archive_dirs不能在數據目錄中，目錄權限要求是700。

功能3:頁面跟蹤

頁面跟蹤是為了優化增量備份的效率，減少不必要的數據頁面掃描。

增量備份目前有三種掃描模式:

Page-track:使用LSN來精確地跟蹤自上次備份以來修改過的頁面，并且只復制這些頁面，這是最快的。

Optimal:掃描自上次備份以來修改過的InnoDB數據文件，找出并復制修改過的頁面。根據系統時間的不同，使用時會有一些限制。

全掃描:掃描所有InnoDB數據文件，找出并復制自上次備份以來修改過的頁面是最慢的。

1.使用頁面跟蹤增量備份，您需要首先安裝備份組件。

2.在完全準備好之前打開頁面跟蹤。

3.完全備份后，進行增量備份時，指定如果滿足頁面跟蹤條件，則默認使用page-track模式，否則使用全掃描模式，也可以指定-incrementalpage-track。

增量基礎有三個選項。

Last_backup:在之前備份的基礎上，之前的備份可以是附加備份，也可以是完全備份。這樣所有的備份之間可能會有多次添加，每次的增量可能都比較小，但是恢復的時候需要一次一次的合并。

Last_full_backup:基于之前的完整備份，添加的。這樣以后備份會更大，但恢復時只需要合并最后一次增量備份。

Dir:基于以前的備份目錄。之前的備份可以是附加備份，也可以是完整備份。

與全掃描和頁跟蹤相比，當改變的頁數小于總頁數的50%時，備份效率至少可以提高一倍。

Page-track模式磁盤讀寫平衡，表示讀寫都是修改頁面。

全掃描模式磁盤讀寫差別很大，表示讀取了很多未修改的頁面。

mysql刪除的數據庫怎么還原？

在求解過程中，進行了以下嘗試:

1.如果開啟了日志，mysqlbinlog可以直接使用日志進行恢復。

2.如果刪除了整個表而不是表中的部分數據，可以嘗試在刪除后立即用磁盤數據恢復軟件恢復。

(因為刪除表后會刪除文件，表的部分數據也會被刪除，但是文件還是存在的。)

3.找一家數據恢復公司，用工具分析ibdata1。(分析過程一頁一頁的參考，看有沒有歷史記錄。在了解數據表結構的前提下，當數據庫損壞，除了ibdata1外無常使用時，應嘗試使用ibdata1恢復數據，而不是刪除表數據后再恢復。

(實際上，該文件用于存儲現有的表數據，但也可以設置為每個表一個文件。)

有兩個文件，ib_logfile0和ib_logfile1。其實這兩個文件記錄了Mysql的一些事務日志，是Mysql自己使用的。這個文件用文本工具打開后，有大量，但是可以找到少量刪除數據的插入記錄。幾個通過前后語句找出原文，最后通過事務日志恢復被刪除的文件。注意:使用事務日志進行恢復有幾個先決條件。

1.知道被刪除數據的大概位置，不要不要看這里，新的數據不斷地入那里。

2.因為有大量，所以適合找少量數據，而不是用于大量數據的恢復，浪費體力。

3.如果二進制日志沒有打開，也沒有備份，那么只能用這種恢復。