1:官方百萬級別的測試數(shù)據(jù)庫:
讓客戶滿意是我們工作的目標,不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶,將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴,公司提供的服務項目有:國際域名空間、虛擬主機、營銷軟件、網(wǎng)站建設(shè)、濮陽縣網(wǎng)站維護、網(wǎng)站推廣。
官方測試數(shù)據(jù)庫github網(wǎng)址:
下載到目錄,解壓即可,運行命令:
2:自己創(chuàng)建簡單測試數(shù)據(jù)庫:
快速隨機生成測試語言的網(wǎng)站:
選擇sql和想生成的字段,點擊生成Generate!生成即可。
在MySQL輸入生成的語句即可。
3:測試備份還原時用到的命令
刪庫跑路測試(先備份好)
還原后查詢庫的表數(shù)據(jù)是否完整。
采用復制整個數(shù)據(jù)存放目錄
1:查看數(shù)據(jù)庫數(shù)據(jù)存放位置
有兩種方法:
1):在數(shù)據(jù)庫中用命令 show variables like 'datadir'; 查看
2):在配置文件中查看,配置了 datadir 目錄的可查看。沒有配置的默認為 /var/lib/mysql/ 位置
Linux中查看配置文件
2:復制目錄或者目錄下某個數(shù)據(jù)庫名
3:還原時直接復制文件夾到數(shù)據(jù)庫目錄即可
mysqldump又可叫做全量備份。
參數(shù) --databases 同 -B ,單獨一個庫,也可省略。
1、備份命令mysqldump格式
格式:mysqldump -h主機名 -P端口 -u用戶名 -p密碼 database 數(shù)據(jù)庫名 文件名.sql
備份testDatabase數(shù)據(jù)庫
2、備份MySQL數(shù)據(jù)庫為帶刪除表的格式
備份MySQL數(shù)據(jù)庫為帶刪除表的格式,能夠讓該備份覆蓋已有數(shù)據(jù)庫而不需要手動刪除原有數(shù)據(jù)庫。
3、直接將MySQL數(shù)據(jù)庫壓縮備份
備份并壓縮
4、備份MySQL數(shù)據(jù)庫某個(些)表
備份testDatabase中的myTable表,不需要用參數(shù) --databases 或者 -B
5、同時備份多個MySQL數(shù)據(jù)庫
同時備份testDatabase和 employees兩個庫
6、備份服務器上所有數(shù)據(jù)庫
參數(shù) --all-databases 同 -A
7、還原MySQL數(shù)據(jù)庫的命令
1) 不指定數(shù)據(jù)名還原,默認生成原數(shù)據(jù)庫名稱,還原所有數(shù)據(jù)庫。
2) 指定數(shù)據(jù)名還原,還原指定單個數(shù)據(jù)庫,需在數(shù)據(jù)庫種預先創(chuàng)建一個testDatabase名稱。
3) 還原壓縮的MySQL數(shù)據(jù)庫
4) 進入數(shù)據(jù)庫用source導入
增量備份是針對于數(shù)據(jù)庫的bin-log日志進行備份的,增量備份是在全量的基礎(chǔ)上進行操作的。增量備份主要是靠mysql記錄的bin-log日志。
1:查看是否開啟bin-log日志
進入mysql輸入命令可查看。
顯示如下為開啟狀態(tài),日志文件在/var/lib/mysql/以binlog.00001的格式保存。
如未開啟,需要在配置文件種配置
2:查看目前使用的bin-log日志文件
進入mysql查看命令。
顯示如下,目前使用的是binlog.000022文件,所有操作都記錄在此文件。
查看當前testDatabase的表myTable數(shù)據(jù)如下,
3:刷新日志,使用新的日志文件(備份)
在命令端執(zhí)行命令
日志文件從 binlog.000022 變?yōu)?binlog.000023
這時相當與已經(jīng)備份成功,備份文件即為上次的binlog.000022日志文件。
4:刪除數(shù)量,從日志還原數(shù)據(jù)
1) 刪除ABC行
查詢以及沒有ABC行列。
2) 恢復數(shù)據(jù)ABC行
退出mysql,在命令端用mysqlbinlog命令恢復到binlog.000022日志狀態(tài)。
進入數(shù)據(jù)庫再次查看數(shù)據(jù),ABC已經(jīng)恢復。
增量備份完成。
增量備份其實就是開啟二進制日志,保留每個操作的sql語句,然后定時備份那個日志文件,并進行刷新以便生成新的日志文件
數(shù)據(jù)備份是數(shù)據(jù)容災的最后一道防線,即便有著兩地三中心的架構(gòu),備份也依然重要。如果備份出問題,備份時影響了交易業(yè)務,備份數(shù)據(jù)無法恢復,這些也是企業(yè)難以承受的。所以選擇合適的備份工具尤為重要。
每個企業(yè)級數(shù)據(jù)庫都會有配套的備份工具,MEB(MySQL Enterprise Backup)就是MySQL企業(yè)版中非常重要的工具之一,是為企業(yè)級客戶提供的數(shù)據(jù)備份方案。
Xtrabackup一直作為MEB 開源版?zhèn)涮ザ嬖?,從MySQL 8.0開始情況可能會變得有所不同。
在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下,MEB備份/恢復體驗會更好,目前xtrabackup還不支持這些特性。
MySQL 企業(yè)版還有哪些功能?
特性1:Backup Lock
8.0之前使用xtrabackup或MEB做物理備份,為了保證備份時InnoDB引擎表與其他引擎數(shù)據(jù)文件、及binlog日志的一致性會上全局讀鎖,再拷貝非InnoDB文件,這期間MySQL會變成只讀,數(shù)據(jù)無法寫入。表數(shù)量越多,可能加上時間越長,如果使用的xtrabackup 不小心沒加rsync參數(shù),逐個拷貝frm文件,鎖定時間會更長,對業(yè)務影響較大。
我曾遇到過部署在虛擬機的實例有12000多張表,當時使用的xtrabackup,備份腳本中沒加rsync參數(shù),結(jié)果鎖了十幾分鐘,而MEB就沒有這樣的問題。
MySQL 8.0支持輕量級備份鎖 LOCK INSTANCE FOR BACKUP,數(shù)據(jù)字典也重構(gòu)了由InnoDB存儲。若不創(chuàng)建非InnoDB表,MEB默認使用備份鎖獲取binlog日志一致性位置,并阻止DDL操作,但不影響DML操作。
只有InnoDB表,僅上備份鎖
請點擊輸入圖片描述
若有非InnoDB表,上全局鎖
請點擊輸入圖片描述
特性2:Redo Log Archiving
MEB能做到在線熱備,備份時不影響數(shù)據(jù)庫讀寫,這是利用了InnoDB事務日志,在備份期間持續(xù)監(jiān)視redo log的變化,讀取增量變化,寫入到ibbackup_logfile,也就不需要上鎖來保障備份一致性。(對非InnoDB的文件需要上讀鎖拷貝)
如果備份期間數(shù)據(jù)庫寫入負載特別大,而寫入ibbackup_logfile速度較慢,redo log size也不大,很可能會出現(xiàn)ibbackup_logfile的寫入速度跟不上redo log記錄生成速度,redo log 空間不夠時需要覆寫日志文件,那么來不及寫入ibbackup_logfile的記錄會丟失,導致備份失敗。
MEB 4.1對此做了優(yōu)化,將redo log處理線程拆分成多線程分工合作,提高處理redo log的效率,降低了redo log覆寫造成備份失敗的概率,但redo log新增速度和ibbackup_logfile寫入速度懸殊太大,問題依然會發(fā)生。
MySQL 8.0.17支持了redo log archiving 徹底解決了此問題,備份前設(shè)置innodb_redo_log_archive_dirs,指定redo log歸檔目錄。MEB備份時自動開啟日志歸檔,當checkpoint時會將舊記錄歸檔到此目錄,后續(xù)從歸檔文件中讀取redo日志記錄,避免了覆寫可能導致的redo記錄丟失。
請點擊輸入圖片描述
注意:innodb_redo_log_archive_dirs 不能在數(shù)據(jù)目錄下,目錄權(quán)限要求是700
特性3:Page Tracking
Page Tracking 是為優(yōu)化增量備份效率,減少不必要的數(shù)據(jù)頁掃描。
增量備份當前有3種掃描模式:
page-track:利用LSN精確跟蹤上次備份之后被修改頁面,僅復制這些頁面,效率最快。
optimistic:掃描上次備份之后被修改的InnoDB 數(shù)據(jù)文件中,找出并拷貝修改的頁面。依賴系統(tǒng)時間,使用存在限制。
full-scan:掃描所有InnoDB數(shù)據(jù)文件,找出并拷貝自上次備份之后修改的頁面,效率最慢
1、利用page-track增量備份,需先安裝備份組件
mysql INSTALL COMPONENT "";
2、在全備前開啟page-track
SELECT mysqlbackup_page_track_set(true);
3、全備之后,做增量備份時指定若滿足page tracking條件,默認會使用page-track模式,否則會使用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:基于前一次備份做增備,前一次備份可能是增備,也可能是全備。這種方式全備之間可能會有多個增備,每次增量可能比較小,但恢復時需要逐個合并。
last_full_backup:基于前一次全備做增備。這種方式增備會越往后體積可能越大,但恢復時只需要合并最后一次增量備份。
dir:基于前一次的備份目錄,前一次備份可能是增備,也可能是全備。
測試對比full-scan 和page-track ,在變更頁小于總體50%的情況下 ,備份效率至少能有1倍的速度提升。
page-track 模式 磁盤讀寫均衡,說明讀寫的都是修改頁面。
請點擊輸入圖片描述
full-scan模式 磁盤讀寫差別很大,說明讀了很多未修改的頁面。
請點擊輸入圖片描述
根據(jù)增量需求更改你的原始表,例如增加update_time時間戳字段,根據(jù)更新時間獲取增量,注意刪除操作,可以通過設(shè)置刪除標記字段來表示,不要進行物理刪除。
mysql主從備份,根據(jù)binlog來實時同步更新變化?;蛘咦约豪inlog解析,更新目標數(shù)據(jù)
echo "" $eMailFile
echo $(date +"%y-%m-%d %H:%M:%S") $eMailFile
#
# 刷新日志,使數(shù)據(jù)庫使用新的二進制日志文件
$mysqlDir/bin/mysqladmin -u$user -p$userPWD flush-logs
cd $dataDir
# 得到二進制日志列表
fileList=`cat $HOSTNAME-bin.index`
iCounter=0
for file in $fileList
do
iCounter=`expr $iCounter + 1`
done
nextNum=0
iFile=0
for file in $fileList
do
binLogName=`basename $file`
nextNum=`expr $nextNum + 1`
# 跳過最后一個二進制日志(數(shù)據(jù)庫當前使用的二進制日志文件)
if [[ $nextNum == $iCounter ]]; then
echo "Skip lastest!" /dev/null
else
dest=$dailyBackupDir/$binLogName
# 跳過已經(jīng)備份的二進制日志文件
if [[ -e $dest ]]; then
echo "Skip exist $binLogName!" /dev/null
else
# 備份日志文件到備份目錄
cp $binLogName $dailyBackupDir
if [[ $? == 0 ]]; then
iFile=`expr $iFile + 1`
echo "$binLogName Backup Success!" $eMailFile
fi
fi
fi
done
if [[ $iFile == 0 ]];then
echo "No Binlog Backup!" $eMailFile
else
echo "Backup $iFile File(s)." $eMailFile