Mysql實(shí)時備份實(shí)現(xiàn)方法？

數(shù)據(jù)備份是數(shù)據(jù)容災(zāi)的最后一道防線。即使是兩地三中心的架構(gòu)，備份依然重要。如果備份出現(xiàn)問題，備份過程中交易業(yè)務(wù)會受到影響，備份數(shù)據(jù)無法恢復(fù)，這也是企業(yè)無法承受的。因此，選擇合適的備份工具尤為重要。

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

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

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

MySQL企業(yè)版還有哪些功能？

功能1:備份鎖

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

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

MySQL8.0支持輕量級備份鎖lock實(shí)例進(jìn)行備份，數(shù)據(jù)字典由InnoDB重構(gòu)存儲。如果沒有創(chuàng)建非InnoDB表，MEB會默認(rèn)使用備份鎖獲取binlog日志的一致性位置，阻止DDL操作，但不會影響DML操作。

只有InnoDB表，只有備份鎖。

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

功能2:重做日志歸檔

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

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

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

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

注意:innodb_redo_log_archive_dirs不能在數(shù)據(jù)目錄中，目錄權(quán)限要求是700。

功能3:頁面跟蹤

頁面跟蹤是為了優(yōu)化增量備份的效率，減少不必要的數(shù)據(jù)頁面掃描。

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

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

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

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

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

2.在完全準(zhǔn)備好之前打開頁面跟蹤。

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

增量基礎(chǔ)有三個選項(xiàng)。

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

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

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

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

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

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

mysql刪除的數(shù)據(jù)庫怎么還原？

在求解過程中，進(jìn)行了以下嘗試:

1.如果開啟了日志，mysqlbinlog可以直接使用日志進(jìn)行恢復(fù)。

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

(因?yàn)閯h除表后會刪除文件，表的部分?jǐn)?shù)據(jù)也會被刪除，但是文件還是存在的。)

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

(實(shí)際上，該文件用于存儲現(xiàn)有的表數(shù)據(jù)，但也可以設(shè)置為每個表一個文件。)

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

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

2.因?yàn)橛写罅浚赃m合找少量數(shù)據(jù)，而不是用于大量數(shù)據(jù)的恢復(fù)，浪費(fèi)體力。

3.如果二進(jìn)制日志沒有打開，也沒有備份，那么只能用這種恢復(fù)。