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

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

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

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

Xtrabackup一直作為MEB的開(kāi)源備胎存在，從MySQL 8.0開(kāi)始情況可能會(huì)有所不同。

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

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

功能1:備份鎖

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

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

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

只有InnoDB表，只有備份鎖。

如果有一個(gè)非InnoDB表，請(qǐng)將其全局鎖定。

功能2:重做日志歸檔

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

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

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

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

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

功能3:頁(yè)面跟蹤

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

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

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

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

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

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

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

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

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

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

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

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

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

Page-track模式磁盤讀寫(xiě)平衡，表示讀寫(xiě)都是修改頁(yè)面。

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

mysql是用什么實(shí)現(xiàn)的主從復(fù)制，如何解決的讀寫(xiě)分離mycat？

改變我的貓 從日志模式切換到調(diào)試模式。執(zhí)行sql后，通過(guò)查看日志中被執(zhí)行節(jié)點(diǎn)的ip，就知道是不是自己設(shè)置的讀節(jié)點(diǎn)。