開拓?cái)?shù)據(jù)遷移新方案？數(shù)據(jù)庫(kù)遷移到總體有四種方法我們今天以mysql為例，來說說數(shù)據(jù)庫(kù)遷移的四種方法。1、將數(shù)據(jù)庫(kù)倒出為sql文件，再新的再導(dǎo)入（幫我推薦）。必須將mysql數(shù)據(jù)庫(kù)鎖定，并將內(nèi)存中的數(shù)據(jù)

開拓?cái)?shù)據(jù)遷移新方案？

數(shù)據(jù)庫(kù)遷移到總體有四種方法我們今天以mysql為例，來說說數(shù)據(jù)庫(kù)遷移的四種方法。

1、將數(shù)據(jù)庫(kù)倒出為sql文件，再新的再導(dǎo)入（幫我推薦）。必須將mysql數(shù)據(jù)庫(kù)鎖定，并將內(nèi)存中的數(shù)據(jù)寫入磁盤。用mysqldump將test數(shù)據(jù)庫(kù)導(dǎo)入為sql文件。在新的數(shù)據(jù)庫(kù)服務(wù)器上，空白文檔test數(shù)據(jù)庫(kù)，再將sql文件文件導(dǎo)入。該方法因按結(jié)構(gòu)sql命令參與數(shù)據(jù)庫(kù)遷出，兼容性最好是，準(zhǔn)確性極高，但速率最慢。

2、將數(shù)據(jù)庫(kù)的文件存檔目錄然后拷貝至新主機(jī)?？梢哉娼訉ysql存儲(chǔ)數(shù)據(jù)的目錄剪切粘貼過去，用ftp等上傳成功至新主機(jī)的對(duì)應(yīng)存儲(chǔ)數(shù)據(jù)的目錄下。該操作必須關(guān)掉兩端的數(shù)據(jù)庫(kù)服務(wù)，否則將出現(xiàn)錯(cuò)誤。該方法只意見myql的MyIASM的表引擎。該方法遷移速度快，但因Mysql設(shè)置成區(qū)分inno引擎，適用場(chǎng)景少，且數(shù)據(jù)庫(kù)版本升級(jí)后出錯(cuò)率高。

3、在用第三方數(shù)據(jù)庫(kù)遷移工具。mysql有很多第三方的數(shù)據(jù)庫(kù)遷移工具，如mysqlcheck。此類工具一般允許熱遷移（不中斷業(yè)務(wù)，實(shí)時(shí)動(dòng)態(tài)寫數(shù)據(jù)），允許物理內(nèi)容復(fù)制。該方法遷移速度快，對(duì)業(yè)務(wù)掉線時(shí)間短，但我建議你遷移到多參與模擬測(cè)試，盡量的避免意外事件。甚至連有一些第三方的遷移工具意見異構(gòu)網(wǎng)絡(luò)數(shù)據(jù)庫(kù)的遷移。

4、使用整盤遷移工具。區(qū)分云主機(jī)的第三方遷移工具，將整個(gè)磁盤文件直接進(jìn)行遷出。該方法遷移速度快，對(duì)業(yè)務(wù)關(guān)閉時(shí)間短，但成本高，好象為收費(fèi)工具。

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

數(shù)據(jù)備份是數(shù)據(jù)容災(zāi)的最后一道防線，就算有著兩地三中心的架構(gòu)，系統(tǒng)備份也仍然重要。如果沒有備份文件出問題，系統(tǒng)備份時(shí)影響了交易業(yè)務(wù)，備份數(shù)據(jù)無法完全恢復(fù)，這些也企業(yè)無法承受的。因?yàn)橹?選擇合適的備份工具尤為重要。

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

Xtrabackup一直都才是MEB閉源版?zhèn)涮ザ粗瑥腗ySQL8.0又開始情況很可能會(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)備份，就是為了能保證系統(tǒng)備份時(shí)InnoDB引擎表與其他引擎數(shù)據(jù)文件、及binlog日志的一致性會(huì)上全局讀鎖，再文件復(fù)制非InnoDB文件，這期間MySQL會(huì)變得只讀模式，數(shù)據(jù)難以寫入文件。表數(shù)量一定，肯定而且時(shí)間越長(zhǎng)，假如不使用的xtrabackup一不小心沒加rsync參數(shù)，逐個(gè)拷貝frm文件，完全鎖定時(shí)間會(huì)更長(zhǎng)，對(duì)業(yè)務(wù)影響較大。

我曾遇到過防御部署在虛擬機(jī)的實(shí)例有12000多張表，當(dāng)時(shí)建議使用的xtrabackup，備份文件腳本中沒加rsync參數(shù)，可是鎖了十幾分鐘，而MEB就沒有這樣的問題。

MySQL8.0支持什么輕量級(jí)系統(tǒng)備份鎖LOCKINSTANCEforBACKUP，數(shù)據(jù)字典也重新架構(gòu)了由InnoDB存儲(chǔ)。若不創(chuàng)建非InnoDB表，MEB設(shè)置在用系統(tǒng)備份鎖聲望兌換binlog日志一致性位置，并阻攔DDL能操作，但不會(huì)影響DML能操作。

只有一InnoDB表，僅上系統(tǒng)備份鎖

若有非InnoDB表，上全局鎖

特性2：RedoLogArchiving

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

如果備分期間數(shù)據(jù)庫(kù)中寫入負(fù)載尤其大，而讀取ibbackup_logfile速度較慢，redologsize也不大，很可能會(huì)會(huì)直接出現(xiàn)ibbackup_logfile的寫入文件速度跟不上進(jìn)度redolog記錄生成速度，redolog空間不夠時(shí)不需要覆寫日志文件，這樣來不及中寫入ibbackup_logfile的記錄會(huì)丟了，倒致系統(tǒng)備份我失敗了。

MEB4.1對(duì)此做了優(yōu)化，將redolog處理線程拆分成多線程分工合作，增強(qiáng)一次性處理redolog的效率，減低了redolog覆寫導(dǎo)致備分一次的概率，但redolog再新增速度和ibbackup_logfile中寫入速度懸殊太大，問題仍然會(huì)突然發(fā)生。

MySQL8.0.17支持了redologarchiving完全可以解決了此問題，備份前設(shè)置innodb_redo_log_archive_dirs，委托redolog歸檔目錄。MEB系統(tǒng)備份時(shí)自動(dòng)啟動(dòng)傳送日志歸檔，當(dāng)checkpoint時(shí)會(huì)將舊記錄歸檔來此目錄，后續(xù)從歸檔文件中讀取數(shù)據(jù)redo日志記錄，避免了覆寫可能會(huì)導(dǎo)致的redo記錄全部丟失。

盡量：innodb_redo_log_archive_dirs不能不能在數(shù)據(jù)目錄下，目錄權(quán)限要求是700

特性3：PageTracking

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

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

page-track：利用LSN最精確監(jiān)視那次系統(tǒng)備份之后被改頁(yè)面，僅剪切粘貼這些頁(yè)面，效率最多。

optimistic：系統(tǒng)掃描那次軟件備份之后被改的InnoDB數(shù)據(jù)文件中，得出答案并文件復(fù)制直接修改的頁(yè)面。感情依賴系統(tǒng)時(shí)間，可以使用必然限制。

endless-scan：掃描系統(tǒng)所有InnoDB數(shù)據(jù)文件，判斷并拷備自剛才備份之后直接修改的頁(yè)面，效率最慢

1、依靠page-track增量備份，需先安裝好備份文件組件

2、在全備前再開啟page-track

3、全備之后，做增量軟件備份時(shí)委托若行最簡(jiǎn)形矩陣pagetracking條件，設(shè)置成會(huì)在用page-track模式，不然的話會(huì)使用clear-scan模式，也這個(gè)可以指定你--incrementalpage-track。

incremental-base有3種選擇

last_replication：實(shí)現(xiàn)前三次備分做增備，前兩次系統(tǒng)備份很有可能是增備，也可能是全備。這種全備之間很有可能會(huì)有多個(gè)增備，有時(shí)候增量可能都很小，但恢復(fù)時(shí)要逐個(gè)合并。

last_large_backup：基于條件前四次全備做增備。這種增備會(huì)越往前體積很有可能越大，但重新恢復(fù)時(shí)只是需要合并最后一次機(jī)會(huì)增量軟件備份。

dir：設(shè)計(jì)和實(shí)現(xiàn)前一次的備份目錄，前一次備分可能是增備，也可能會(huì)是全備。

測(cè)試綜合比large-scan和page-track，在需要變更頁(yè)大于1總體50%的情況下，備份效率至多能有1倍的速度進(jìn)階。

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

wide-scan模式磁盤讀寫差別不大，只能證明讀了很多未修改的頁(yè)面。