Mysql實(shí)時(shí)備份實(shí)現(xiàn)方法？數(shù)據(jù)備份是數(shù)據(jù)容災(zāi)的最后一道防線，就算是有著兩地三中心的架構(gòu)，備分也依然重要。如果不是系統(tǒng)備份出問(wèn)題，備份時(shí)會(huì)影響了交易業(yè)務(wù)，備份數(shù)據(jù)難以可以恢復(fù)，這些又是企業(yè)難以承受的。

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

數(shù)據(jù)備份是數(shù)據(jù)容災(zāi)的最后一道防線，就算是有著兩地三中心的架構(gòu)，備分也依然重要。如果不是系統(tǒng)備份出問(wèn)題，備份時(shí)會(huì)影響了交易業(yè)務(wù)，備份數(shù)據(jù)難以可以恢復(fù)，這些又是企業(yè)難以承受的。所以我選擇類型比較好的備份工具尤為重要。

每個(gè)企業(yè)級(jí)數(shù)據(jù)庫(kù)都會(huì)有對(duì)應(yīng)的備份工具，MEB(MySQL Enterprise Backup)應(yīng)該是MySQL企業(yè)版中非常重要的工具之一，是為企業(yè)級(jí)客戶提供給的數(shù)據(jù)備份方案。

Xtrabackup始終以及MEB開(kāi)放源代碼版?zhèn)涮ザ嬖诘?，從MySQL8.0開(kāi)始情況很可能會(huì)變得更加有所有所不同。

在MySQL8.0的BackupLock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB備份/重新恢復(fù)體驗(yàn)會(huì)更好，目前xtrabackup還不支持這些特性。

MySQL企業(yè)版另外哪些功能？

特性1：BackupLock

8.0之前不使用xtrabackup或MEB做物理系統(tǒng)備份，就是為了絕對(duì)的保證系統(tǒng)備份時(shí)InnoDB引擎表與其他引擎數(shù)據(jù)文件、及binlog日志的一致性會(huì)上全局讀鎖，再拷備非InnoDB文件，這期間MySQL會(huì)變成禁止讀，數(shù)據(jù)無(wú)法寫(xiě)入。表數(shù)量就會(huì)，可能會(huì)另外時(shí)間越長(zhǎng)，如果沒(méi)有在用的xtrabackup不小心沒(méi)加rsync參數(shù)，逐個(gè)拷備frm文件，鎖定住時(shí)間會(huì)更長(zhǎng)，對(duì)業(yè)務(wù)影響較大。

我曾遇到了過(guò)重新部署在虛擬機(jī)的實(shí)例有12000多張表，當(dāng)時(shí)不使用的xtrabackup，備份腳本中沒(méi)加rsync參數(shù)，最后鎖了十幾分鐘，而MEB就沒(méi)有這樣的問(wèn)題。

MySQL8.0接受輕量級(jí)軟件備份鎖LOCKINSTANCEafterBACKUP，數(shù)據(jù)字典也重新架構(gòu)了由InnoDB存儲(chǔ)。若不修改非InnoDB表，MEB系統(tǒng)默認(rèn)使用系統(tǒng)備份鎖某些binlog日志一致性位置，并阻止DDL能操作，但不影響DML你操作。

僅有InnoDB表，僅上軟件備份鎖

若有非InnoDB表，上全局鎖

特性2：RedoLogArchiving

MEB能做到在線熱備，備分時(shí)不影響不大數(shù)據(jù)庫(kù)讀寫(xiě)，這是利用了InnoDB事務(wù)日志，在備分期間短短監(jiān)視r(shí)edolog的變化，讀取數(shù)據(jù)增量變化，寫(xiě)入到到ibbackup_logfile，也就不需要上鎖來(lái)保障系統(tǒng)備份一致性。(對(duì)非InnoDB的文件要上讀鎖u盤(pán)拷貝)

要是備分期間數(shù)據(jù)庫(kù)寫(xiě)入負(fù)載最重要的大，而中寫(xiě)入ibbackup_logfile速度較慢，redologsize也不大，很很可能會(huì)直接出現(xiàn)ibbackup_logfile的中寫(xiě)入速度太差redolog記錄生成速度，redolog空間太差時(shí)需要覆寫(xiě)日志文件，這樣的話來(lái)不及讀取ibbackup_logfile的記錄會(huì)丟了，可能導(dǎo)致備份失敗。

MEB4.1對(duì)此做了優(yōu)化，將redolog處理線程word文檔合并成多線程分工合作，增加處理redolog的效率，減低了redolog覆寫(xiě)倒致備份文件失敗的概率，但redolog新增速度和ibbackup_logfile寫(xiě)入到速度懸殊太大，問(wèn)題仍然會(huì)發(fā)生了什么。

MySQL8.0.17意見(jiàn)了redologarchiving全部幫忙解決了此問(wèn)題，軟件備份前系統(tǒng)設(shè)置innodb_redo_log_archive_dirs，指定你redolog歸檔目錄。MEB系統(tǒng)備份時(shí)自動(dòng)傳送日志歸檔，當(dāng)checkpoint時(shí)會(huì)將舊記錄歸檔來(lái)此目錄，現(xiàn)從歸檔文件中讀取數(shù)據(jù)redo日志記錄，避免了覆寫(xiě)很有可能會(huì)造成的redo留下記錄丟了。

注意一點(diǎn)：innodb_redo_log_archive_dirs沒(méi)法在數(shù)據(jù)目錄下，目錄權(quán)限要求是700

特性3：PageTracking

PageTracking是為優(yōu)化增量備分效率，增加不必要的數(shù)據(jù)頁(yè)掃描。

增量備份文件當(dāng)前有3種掃描模式：

page-track：憑借LSN計(jì)算精確潛進(jìn)來(lái)前段時(shí)間備分之后被直接修改頁(yè)面，僅復(fù)制這些頁(yè)面，效率最方便。

optimistic：掃描系統(tǒng)上次系統(tǒng)備份之后被可以修改的InnoDB數(shù)據(jù)文件中，找出并拷貝改的頁(yè)面。依賴感系統(tǒng)時(shí)間，在用存在限制。

endless-scan：掃描后所有InnoDB數(shù)據(jù)文件，判斷并文件復(fù)制自那次備分之后改的頁(yè)面，效率最慢

1、憑借page-track增量備分，需先直接安裝軟件備份組件

2、在全備前自動(dòng)打開(kāi)page-track

3、全備之后，做增量備份文件時(shí)更改若滿足pagetracking條件，系統(tǒng)默認(rèn)會(huì)在用page-track模式，否則會(huì)可以使用clear-scan模式，也可以更改--incrementalpage-track。

incremental-base有3種選擇

last_provisioning：基于條件前四次系統(tǒng)備份做增備，前一次備分肯定是增備，也可能會(huì)是全備。這種全備之間肯定會(huì)有多個(gè)增備，每次來(lái)增量可能都很小，但復(fù)原時(shí)需要逐一不合并。

last_clear_backup：實(shí)現(xiàn)前一次全備做增備。這種增備會(huì)越向前體積很有可能越大，但復(fù)原時(shí)只必須合并最后一次增量系統(tǒng)備份。

dir：基于組件前一次的備份目錄，前三次備份文件很可能是增備，也很有可能是全備。

測(cè)試差別clear-scan和page-track，在變更手續(xù)頁(yè)大于總體50%的情況下，備份效率至多能有1倍的速度修為提升。

page-track模式磁盤(pán)讀寫(xiě)均衡，只能證明讀寫(xiě)的大都直接修改頁(yè)面。

large-scan模式磁盤(pán)讀寫(xiě)差別很小，只能說(shuō)明讀了很多未改的頁(yè)面。

如何實(shí)現(xiàn)Mysql數(shù)據(jù)庫(kù)每天自動(dòng)備份定時(shí)備份？

有兩種方法：

1、是從crond定時(shí)任務(wù)，用mysqldump自動(dòng)備份數(shù)據(jù)庫(kù)2、按照存儲(chǔ)過(guò)程，事件配合自動(dòng)備份數(shù)據(jù)庫(kù)