提供備份的本地2種方法：
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供合江網(wǎng)站建設(shè)、合江做網(wǎng)站、合江網(wǎng)站設(shè)計(jì)、合江網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、合江企業(yè)網(wǎng)站模板建站服務(wù)，十載合江做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
命令行備份到服務(wù)器上下載到本地；
通過客戶端工具將mysql備份并同步下載到本地或者查詢導(dǎo)出到本地；
本例以本地服務(wù)器為 RHEL6/x64 系統(tǒng)，備份文件存儲(chǔ)路徑為?/home/mysql/?為例。
下載云數(shù)據(jù)庫?物理備份文件?并上傳至目標(biāo)服務(wù)器。備份文件獲取方法請(qǐng)參見?下載備份數(shù)據(jù)。如果目標(biāo)服務(wù)器可以訪問源實(shí)例，您也可以使用?wget "url"?下載備份文件。其中?url?為備份文件下載地址。
切換路徑到備份文件所在路徑。
cd /home/mysql/
解壓備份文件。
其中，filename.tar.gz?為備份文件名。
tar vizxf filename.tar.gz
檢查解壓后文件包含的數(shù)據(jù)庫是否正確。
系統(tǒng)顯示如下，其中?db0dz1rv11f44yg2、mysql?和?test?為云數(shù)據(jù)庫中存在的數(shù)據(jù)庫。
-rw-r--r-- 1 root root ? ? ? 269 Aug 19 18:15 backup-my.cnf
drwxr-xr-x 2 root root ? ? ?4096 Aug 21 10:31 db0dz1rv11f44yg2
-rw-rw---- 1 root root 209715200 Aug ?7 10:44 ibdata1
drwxr-xr-x 2 root root ? ? ?4096 Aug 21 10:31 mysql
drwxr-xr-x 2 root root ? ? ?4096 Aug 21 10:31 test
-rw-r--r-- 1 root root ? ? ? ?10 Aug 19 18:15 xtrabackup_binary
-rw-r--r-- 1 root root ? ? ? ?23 Aug 19 18:15 xtrabackup_binlog_info
-rw-r--r-- 1 root root ? ? ? ?77 Aug 19 18:15 xtrabackup_checkpoints
-rw-r--r-- 1 root root ? ? ?2560 Aug 19 18:15 xtrabackup_logfile
-rw-r--r-- 1 root root ? ? ? ?72 Aug 19 18:15 xtrabackup_slave_info
cd filename/
ll
恢復(fù)數(shù)據(jù)文件。
系統(tǒng)顯示?innobackupex: completed OK!，則數(shù)據(jù)恢復(fù)成功。
innobackupex --defaults-file=./backup-my.cnf --apply-log ./
修改配置文件。將解壓文件?backup-my.cnf?中的?innodb_fast_checksum、innodb_page_size、innodb_log_block_size注釋掉，并且添加?datadir=/home/mysql，如下所示。
# This MySQL options file was generated by innobackupex-1.5.1.
# The MySQL Server
[mysqld]
innodb_data_file_path=ibdata1:200M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=524288000
#innodb_fast_checksum=0
#innodb_page_size=16364
#innodb_log_block_size=512
datadir=/home/mysql/
重裝 MySQL 系統(tǒng)庫，取得數(shù)據(jù)庫的 root 權(quán)限。
系統(tǒng)顯示如下，則 mysql 系統(tǒng)庫重裝成功。
Installing MySQL system table...
OK
Filling help table...
OK
rm -rf mysql
mysql_install_db --user=mysql --datadir=/home/mysql/
修改文件屬主。
chown -R mysql:mysql /home/mysql/
啟動(dòng) mysqld 進(jìn)程。
mysqld_safe --defaults-file=/home/mysql/backup-my.cnf
使用客戶端登錄數(shù)據(jù)庫。
mysql –u root –p
驗(yàn)證數(shù)據(jù)庫是否完整。
系統(tǒng)顯示入選，則數(shù)據(jù)庫恢復(fù)成功。
+--------------------+
| Database ? ? ? ? ? |
+--------------------+
| information_schema |
| db0dz1rv11f44yg2 ? |
| mysql ? ? ? ? ? ? ?|
| performance_schema |
| test ? ? ? ? ? ? ? |
+--------------------+
show databases;
數(shù)據(jù)備份是數(shù)據(jù)容災(zāi)的最后一道防線，即便有著兩地三中心的架構(gòu)，備份也依然重要。如果備份出問題，備份時(shí)影響了交易業(yè)務(wù)，備份數(shù)據(jù)無法恢復(fù)，這些也是企業(yè)難以承受的。所以選擇合適的備份工具尤為重要。
每個(gè)企業(yè)級(jí)數(shù)據(jù)庫都會(huì)有配套的備份工具，MEB(MySQL Enterprise Backup)就是MySQL企業(yè)版中非常重要的工具之一，是為企業(yè)級(jí)客戶提供的數(shù)據(jù)備份方案。
Xtrabackup一直作為MEB 開源版?zhèn)涮ザ嬖冢瑥腗ySQL 8.0開始情況可能會(huì)變得有所不同。
在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB備份/恢復(fù)體驗(yàn)會(huì)更好，目前xtrabackup還不支持這些特性。
MySQL 企業(yè)版還有哪些功能？
特性1：Backup Lock
8.0之前使用xtrabackup或MEB做物理備份，為了保證備份時(shí)InnoDB引擎表與其他引擎數(shù)據(jù)文件、及binlog日志的一致性會(huì)上全局讀鎖，再拷貝非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ù)，結(jié)果鎖了十幾分鐘，而MEB就沒有這樣的問題。
MySQL 8.0支持輕量級(jí)備份鎖 LOCK INSTANCE FOR BACKUP，數(shù)據(jù)字典也重構(gòu)了由InnoDB存儲(chǔ)。若不創(chuàng)建非InnoDB表，MEB默認(rèn)使用備份鎖獲取binlog日志一致性位置，并阻止DDL操作，但不影響DML操作。
只有InnoDB表，僅上備份鎖
請(qǐng)點(diǎn)擊輸入圖片描述
若有非InnoDB表，上全局鎖
請(qǐng)點(diǎn)擊輸入圖片描述
特性2：Redo Log Archiving
MEB能做到在線熱備，備份時(shí)不影響數(shù)據(jù)庫讀寫，這是利用了InnoDB事務(wù)日志，在備份期間持續(xù)監(jiān)視r(shí)edo log的變化，讀取增量變化，寫入到ibbackup_logfile，也就不需要上鎖來保障備份一致性。(對(duì)非InnoDB的文件需要上讀鎖拷貝)
如果備份期間數(shù)據(jù)庫寫入負(fù)載特別大，而寫入ibbackup_logfile速度較慢，redo log size也不大，很可能會(huì)出現(xiàn)ibbackup_logfile的寫入速度跟不上redo log記錄生成速度，redo log 空間不夠時(shí)需要覆寫日志文件，那么來不及寫入ibbackup_logfile的記錄會(huì)丟失，導(dǎo)致備份失敗。
MEB 4.1對(duì)此做了優(yōu)化，將redo log處理線程拆分成多線程分工合作，提高處理redo log的效率，降低了redo log覆寫造成備份失敗的概率，但redo log新增速度和ibbackup_logfile寫入速度懸殊太大，問題依然會(huì)發(fā)生。
MySQL 8.0.17支持了redo log archiving 徹底解決了此問題，備份前設(shè)置innodb_redo_log_archive_dirs，指定redo log歸檔目錄。MEB備份時(shí)自動(dòng)開啟日志歸檔，當(dāng)checkpoint時(shí)會(huì)將舊記錄歸檔到此目錄，后續(xù)從歸檔文件中讀取redo日志記錄，避免了覆寫可能導(dǎo)致的redo記錄丟失。
請(qǐng)點(diǎn)擊輸入圖片描述
注意：innodb_redo_log_archive_dirs 不能在數(shù)據(jù)目錄下，目錄權(quán)限要求是700
特性3：Page Tracking
Page Tracking 是為優(yōu)化增量備份效率，減少不必要的數(shù)據(jù)頁掃描。
增量備份當(dāng)前有3種掃描模式：
page-track：利用LSN精確跟蹤上次備份之后被修改頁面，僅復(fù)制這些頁面，效率最快。
optimistic：掃描上次備份之后被修改的InnoDB 數(shù)據(jù)文件中，找出并拷貝修改的頁面。依賴系統(tǒng)時(shí)間，使用存在限制。
full-scan：掃描所有InnoDB數(shù)據(jù)文件，找出并拷貝自上次備份之后修改的頁面，效率最慢
1、利用page-track增量備份，需先安裝備份組件
mysql INSTALL COMPONENT "";
2、在全備前開啟page-track
SELECT mysqlbackup_page_track_set(true);
3、全備之后，做增量備份時(shí)指定若滿足page tracking條件，默認(rèn)會(huì)使用page-track模式，否則會(huì)使用full-scan模式，也可以指定--incremental=page-track。
mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup
incremental-base有3種選擇
last_backup：基于前一次備份做增備，前一次備份可能是增備，也可能是全備。這種方式全備之間可能會(huì)有多個(gè)增備，每次增量可能比較小，但恢復(fù)時(shí)需要逐個(gè)合并。
last_full_backup：基于前一次全備做增備。這種方式增備會(huì)越往后體積可能越大，但恢復(fù)時(shí)只需要合并最后一次增量備份。
dir：基于前一次的備份目錄，前一次備份可能是增備，也可能是全備。
測(cè)試對(duì)比full-scan 和page-track ，在變更頁小于總體50%的情況下 ，備份效率至少能有1倍的速度提升。
page-track 模式 磁盤讀寫均衡，說明讀寫的都是修改頁面。
請(qǐng)點(diǎn)擊輸入圖片描述
full-scan模式 磁盤讀寫差別很大，說明讀了很多未修改的頁面。
請(qǐng)點(diǎn)擊輸入圖片描述
重慶分公司
重慶分公司
