mysql數據庫備份都備份什麼（sql數據庫的備份）

本文目錄一覽：

• 1、MYSQL數據庫備份都備份什麼，除了數據表還需要什麼，怎麼進行備份
• 2、什麼是數據庫備份
• 3、mysql備份方式有哪些
• 4、MySQL備份的幾種常用

MYSQL數據庫備份都備份什麼，除了數據表還需要什麼，怎麼進行備份

備份表結構，（主鍵、索引、等） 表數據；

備份方法2種：1 如果你的開發環境是php的， 下一個phpmyadmin 的mysql web 後台管理中心可進行備份等諸多操作

2：使用CMD 進入 mysql 控制台， 使用mysqldump命令進行備份

什麼是數據庫備份

對於MySQL數據庫，備份與恢復相關的術語包括：備份(backup)、還原(restore)、恢復(recover)、二進制日誌(binlog)，其中備份按照其特性可以分為：物理備份和邏輯備份;冷備、溫備和熱備;完全備份和不完全備份等;常用的備份工具包括：操作系統拷貝、mysqldump等;還原包括物理備份的還原和邏輯備份的還原;下面分別加以介紹和說明。

數據庫備份通俗地說是將數據庫的某一時刻的數據複製了一份;數據庫還原是將備份出的數據替換掉原來數據庫中的數據文件，將備份放回到原來數據庫文件的目錄位置;二進制日誌(BINLOG)記錄數據庫的變更過程，例如創建數據庫、建表、修改表等DDL操作、以及數據表的相關DML操作，這些操作會導致數據庫產生變化，開啟binlog以後導致數據庫產生變化的操作會按照時間順序以“事件”的形式記錄到binlog二進制文件中。

參考上圖，在凌晨2:00，管理員將已開啟二進制日誌的數據庫的數據做了一個完整的備份，隨着時間的推移，仍然有用戶對數據庫進行相關的寫操作(包括：DDL語句、DML語句中的增刪改操作、DCL授權語句和TCL事務處理語句等)，導致了二進制日誌文件寫滿(默認1G)後自動切換;在上午9:37時，由於硬盤出現故障，數據庫用戶不能正常訪問存放在硬盤中的數據庫數據，此時如果數據庫備份和二進制日誌沒有損壞，管理員是可以通過還原備份和恢復二進制日誌的方式挽回數據損失的。

挽回數據損失的過程包括：1.更換新硬盤;2.還原備份;3.重做備份到故障時段的二進制日誌中的語句等;正常情況不會造成數據的丟失，損失的僅僅是一段時間的停機時間。

上例中，還原數據備份時，數據庫中的數據回到了備份時刻的狀態，而二進制日誌中記錄了從備份到故障前一段時間內所有用戶對數據庫的寫操作的語句，只要把這些語句按照時間順序重新運行一遍，所還原的數據就會變成為故障前那一刻的狀態，不會造成數據丟失。因此通常把保存在二進制日誌中的語句重新執行的過程叫做恢復。

mysql備份方式有哪些

數據庫最直接的備份方法就是使用自帶的mysqldump命令進行備份。

1、 mysqldump命令備份數據

在MySQL中提供了命令行導出數據庫數據以及文件的一種方便的工具mysqldump,我們可以通過命令行直接實現數據庫內容的導出dump,首先我們簡單了解一下mysqldump命令用法:

#MySQLdump常用

mysqldump -u root -p –databases 數據庫1 數據庫2 xxx.sql

2、 mysqldump常用操作實例

2.1備份全部數據庫的數據和結構

mysqldump -uroot -p123456 -A /data/mysqlDump/mydb.sql

2.2備份全部數據庫的結構（加 -d 參數）

mysqldump -uroot -p123456 -A -d /data/mysqlDump/mydb.sql

2.3 備份全部數據庫的數據(加 -t 參數)

mysqldump -uroot -p123456 -A -t /data/mysqlDump/mydb.sql

2.4 備份單個數據庫的數據和結構(,數據庫名mydb)

mysqldump -uroot-p123456 mydb /data/mysqlDump/mydb.sql

2.5 備份單個數據庫的結構

mysqldump -uroot -p123456 mydb -d /data/mysqlDump/mydb.sql

2.6 備份單個數據庫的數據

mysqldump -uroot -p123456 mydb -t /data/mysqlDump/mydb.sql2

2.7 備份多個表的數據和結構（數據，結構的單獨備份方法與上同）

mysqldump -uroot -p123456 mydb t1 t2 /data/mysqlDump/mydb.sql

2.8 一次備份多個數據庫

mysqldump -uroot -p123456 –databases db1 db2 /data/mysqlDump/mydb.sql

MySQL備份的幾種常用

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

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

Xtrabackup一直作為MEB 開源版備胎而存在，從MySQL 8.0開始情況可能會變得有所不同。

在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB備份/恢復體驗會更好，目前xtrabackup還不支持這些特性。

MySQL 企業版還有哪些功能？

特性1：Backup Lock

8.0之前使用xtrabackup或MEB做物理備份，為了保證備份時InnoDB引擎表與其他引擎數據文件、及binlog日誌的一致性會上全局讀鎖，再拷貝非InnoDB文件，這期間MySQL會變成只讀，數據無法寫入。表數量越多，可能加上時間越長，如果使用的xtrabackup 不小心沒加rsync參數，逐個拷貝frm文件，鎖定時間會更長，對業務影響較大。

我曾遇到過部署在虛擬機的實例有12000多張表，當時使用的xtrabackup，備份腳本中沒加rsync參數，結果鎖了十幾分鐘，而MEB就沒有這樣的問題。

MySQL 8.0支持輕量級備份鎖 LOCK INSTANCE FOR BACKUP，數據字典也重構了由InnoDB存儲。若不創建非InnoDB表，MEB默認使用備份鎖獲取binlog日誌一致性位置，並阻止DDL操作，但不影響DML操作。

只有InnoDB表，僅上備份鎖

請點擊輸入圖片描述

若有非InnoDB表，上全局鎖

請點擊輸入圖片描述

特性2：Redo Log Archiving

MEB能做到在線熱備，備份時不影響數據庫讀寫，這是利用了InnoDB事務日誌，在備份期間持續監視redo log的變化，讀取增量變化，寫入到ibbackup_logfile，也就不需要上鎖來保障備份一致性。(對非InnoDB的文件需要上讀鎖拷貝)

如果備份期間數據庫寫入負載特別大，而寫入ibbackup_logfile速度較慢，redo log size也不大，很可能會出現ibbackup_logfile的寫入速度跟不上redo log記錄生成速度，redo log 空間不夠時需要覆寫日誌文件，那麼來不及寫入ibbackup_logfile的記錄會丟失，導致備份失敗。

MEB 4.1對此做了優化，將redo log處理線程拆分成多線程分工合作，提高處理redo log的效率，降低了redo log覆寫造成備份失敗的概率，但redo log新增速度和ibbackup_logfile寫入速度懸殊太大，問題依然會發生。

MySQL 8.0.17支持了redo log archiving 徹底解決了此問題，備份前設置innodb_redo_log_archive_dirs，指定redo log歸檔目錄。MEB備份時自動開啟日誌歸檔，當checkpoint時會將舊記錄歸檔到此目錄，後續從歸檔文件中讀取redo日誌記錄，避免了覆寫可能導致的redo記錄丟失。

請點擊輸入圖片描述

注意：innodb_redo_log_archive_dirs 不能在數據目錄下，目錄權限要求是700

特性3：Page Tracking

Page Tracking 是為優化增量備份效率，減少不必要的數據頁掃描。

增量備份當前有3種掃描模式：

page-track：利用LSN精確跟蹤上次備份之後被修改頁面，僅複製這些頁面，效率最快。

optimistic：掃描上次備份之後被修改的InnoDB 數據文件中，找出並拷貝修改的頁面。依賴系統時間，使用存在限制。

full-scan：掃描所有InnoDB數據文件，找出並拷貝自上次備份之後修改的頁面，效率最慢

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模式 磁盤讀寫差別很大，說明讀了很多未修改的頁面。

請點擊輸入圖片描述