mysql如何備份和還原數(shù)據(jù)庫？

備份數(shù)據(jù)庫 使用mysqldump命令備份數(shù)據(jù)庫 復制代碼代碼如下: # 如果要將game數(shù)據(jù)庫進行備份： mysqldump -u root -p game > game_backup.sql # 如果希望備份所有的數(shù)據(jù)庫： mysqldump -u root -p --all-databases > all_backup.sql 還原數(shù)據(jù)庫

1、使用mysql命令還原數(shù)據(jù)庫 將game_backup.sql 還原至 game 數(shù)據(jù)庫： 復制代碼代碼如下: mysql -u root -p game < game_backup.sql

2、使用source命令還原數(shù)據(jù)庫 如果數(shù)據(jù)庫過大，建議可以使用source命令 復制代碼代碼如下: mysql> source game_backup.sql

mysql備份問題，mysql版本5.7.2？

1、你用mysqlpump壓縮備份lz4的后綴名不應該是sql，你要.lz4才行。

mysqlpump --compress-output=LZ4 > dump.lz4

lz4_decompress dump.lz4 dump.txt

2、mysqlpump和mysqldump一樣，屬于邏輯備份，備份以SQL形式的文本保存。

3、這個沒啥好建議，你數(shù)據(jù)庫太大了，本來還想說用XtraBackup工具，但是這個只支持linux系統(tǒng)。

MySQL中,備份數(shù)據(jù)庫的命令是？

使用mysqldump工具進行備份：

1）備份所有數(shù)據(jù)庫： $ mysqldump -uroot -p --all-database > all.sql （2）備份數(shù)據(jù)庫test $ mysqldump -uroot -p test > test.sql （3）備份數(shù)據(jù)庫test下的表emp $ mysqldump -uroot -p test emp > emp.sql （4）備份數(shù)據(jù)庫test下的表emp和dept $ mysqldump -uroot -p test emp dept > emp_dept.sql

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

數(shù)據(jù)備份是數(shù)據(jù)容災的最后一道防線，即便有著兩地三中心的架構，備份也依然重要。如果備份出問題，備份時影響了交易業(yè)務，備份數(shù)據(jù)無法恢復，這些也是企業(yè)難以承受的。所以選擇合適的備份工具尤為重要。

每個企業(yè)級數(shù)據(jù)庫都會有配套的備份工具，MEB(MySQL Enterprise Backup)就是MySQL企業(yè)版中非常重要的工具之一，是為企業(yè)級客戶提供的數(shù)據(jù)備份方案。

Xtrabackup一直作為MEB 開源版?zhèn)涮ザ嬖冢瑥腗ySQL 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ù)，結果鎖了十幾分鐘，而MEB就沒有這樣的問題。

MySQL 8.0支持輕量級備份鎖 LOCK INSTANCE FOR BACKUP，數(shù)據(jù)字典也重構了由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 徹底解決了此問題，備份前設置innodb_redo_log_archive_dirs，指定redo log歸檔目錄。MEB備份時自動開啟日志歸檔，當checkpoint時會將舊記錄歸檔到此目錄，后續(xù)從歸檔文件中讀取redo日志記錄，避免了覆寫可能導致的redo記錄丟失。

注意：innodb_redo_log_archive_dirs 不能在數(shù)據(jù)目錄下，目錄權限要求是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增量備份，需先安裝備份組件

2、在全備前開啟page-track

3、全備之后，做增量備份時指定若滿足page tracking條件，默認會使用page-track模式，否則會使用full-scan模式，也可以指定--incremental=page-track。

incremental-base有3種選擇

last_backup：基于前一次備份做增備，前一次備份可能是增備，也可能是全備。這種方式全備之間可能會有多個增備，每次增量可能比較小，但恢復時需要逐個合并。

last_full_backup：基于前一次全備做增備。這種方式增備會越往后體積可能越大，但恢復時只需要合并最后一次增量備份。

dir：基于前一次的備份目錄，前一次備份可能是增備，也可能是全備。

測試對比full-scan 和page-track ，在變更頁小于總體50%的情況下 ，備份效率至少能有1倍的速度提升。

page-track 模式 磁盤讀寫均衡，說明讀寫的都是修改頁面。

full-scan模式 磁盤讀寫差別很大，說明讀了很多未修改的頁面。

總結

以上是生活随笔為你收集整理的（linux备份mysql）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。