備份高于一切，今天匯總一下常用的幾種備份方法，以及恢復的步驟。
一、mysqldump在日常工作中，我們會使用mysqldump 創建SQL格式的轉儲文件來備份數據庫。或者我們把數據導出后做數據遷移，主備搭建等操作。mysqldump是一個邏輯備份工具,復制原始的數據庫對象定義和表數據產生一組可執行的SQL語句。 默認情況下,生成insert語句，也能生成其它分隔符的輸出或XML格式的文件。
shell>mysqldump[arguments]>file_name
我們簡單來看一下日常的用法：
備份所有的數據庫：
shell>mysqldump–all-databases>dump.sql(不包含INFORMATION_SCHEMA,performance_schema,sys，如果想要導出的話還要結合–skip-lock-tables和–database一起用)
備份指定的數據庫：
shell>mysqldump–databasesdb1db2db3>dump.sql
當我們只備份一個數據的時候可以省去 –databases 直接寫成：mysqldump test > dump.sql 不過有一些細微的差別，如果不加的話，數據庫轉儲輸出不包含創建數據庫和use語句，所以可以不加這個參數直接導入到其它名字的數據庫里。
當然我們也可以只備份某個表 ：
mysqldump–user[username]–password=[password][databasename][table“”notfound/] table_name.sql
了解了簡單的一些用法后我們再著重看一下幾個參數：
- master-data 獲取備份數據的Binlog位置和Binlog文件名，用于通過備份恢復的實例之間建立復制關系時使用，該參數會默認開啟。
- dump-slave 用于在slave上dump數據，建立新的slave。因為我們在使用mysqldump時會鎖表，所以大多數情況下，我們的導出操作一般會在只讀備庫上做，為了獲取主庫的Relay_Master_Log_File和Exec_Master_Log_Pos，需要用到這個參數，不過這個參數只有在5.7以后的才會有
- no-data, -d 不導出任何數據，只導出數據庫表結構
剛剛我們說過在使用mysqldump的時候會鎖表，我們來詳細看一下它的鎖機制。
我們開兩個窗口，在第一個里面執行mysqldump -uroot -pxxxxx –master-data=2 –databases dbname > /tmp/dbnamedate +%F.sql 然后第二個窗口登陸進去，使用show process的 可以看到目前dump的session正在執行。
SELECT /!40001 SQL_NO_CACHE/ * FROM table_name; 可以看到這條SQL正在以no_cache的模式查詢數據。
然后我們在同樣的表上執行一下select，發現被阻塞了。光標一直不返回。
一般遇到這種文件，我們會想是不是有鎖呢？ 為了驗證我們查看一下鎖的信息，可以發現dump的進程實際上是加了鎖的。
一般遇到這種文件，我們會想是不是有鎖呢？ 為了驗證我們查看一下鎖的信息，可以發現dump的進程實際上是加了鎖的。
我們把具體的general_log打開，然后看一下當時的操作：
4101044QueryFLUSH/!40101LOCAL/TABLES 4101044QueryFLUSHTABLESWITHREADLOCK
（關閉所有打開的表，同時對于所有數據庫中的表都加一個讀鎖，直到顯示地執行unlock tables，該操作常常用于數據備份的時候。）
4101044QuerySHOWMASTERSTATUS
（這是因為我用了–master-data=2）
所以這個時候表就會被鎖住。
如果我不加–master-data參數(mysqldump -uroot -pxx –databases db > /tmp/dbnamedate +%F.sql) mysql會顯示的對每一張要備份的表執行 LOCK TABLEStable_name1READ,LOCK TABLEStable_name2READ ，并且也不會有讀的阻塞。
那有沒有不鎖的方法，其實也是有的，就是使用–single-transaction把備份的操作放在一個事務里去進行。
帶上–single-transaction參數的mysqldump備份過程：
如果是5.6版本的MySQL
在備份之間同樣的先FLUSH TABLES WITH READ LOCK，然后設置事務級別SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ，然后開啟一個事務START TRANSACTION進行備份，這個時候備份的過程就很意思，它先創建了一個savepoint，然后把數據庫里的表依次的進行備份，備份完成了之后又回滾到了之前的savepoint，來保證數據的一致性。
如果是5.7版本的MySQL
備份前的操作相同，只是沒有了savepoint。
不過不管是哪個版本，只有InnoDB表是在一個一致性的狀態。其它的任何MyISAM表或內存表是沒有用的。 mysqldump的優勢是可以查看或者編輯十分方便，它也可以靈活性的恢復之前的數據。它也不關心底層的存儲引擎，既適用于支持事務的，也適用于不支持事務的表。不過它不能作為一個快速備份大量的數據或可伸縮的解決方案。如果數據庫過大,即使備份步驟需要的時間不算太久,但有可能恢復數據的速度也會非常慢,因為它涉及的SQL語句插入磁盤I/O,創建索引等等。 對于大規模的備份和恢復,更合適的做法是物理備份,復制其原始格式的數據文件,可以快速恢復:如果你的表主要是InnoDB表,或者如果你有一個InnoDB和MyISAM表,可以考慮使用MySQL的mysqlbackup命令備份。
恢復操作：先看一下當前的數據：
dbadmin@test11:10:34>select*fromt; +——-+ |id| +——-+ |1| +——-+ 1rowinset(0.00sec)
備份；
mysqldump-uroot-proot@1234–master-data=1test>test.sql
模擬增量操作
dbadmin@test11:15:17>insertintotvalues(2); QueryOK,1rowaffected(0.00sec) dbadmin@test11:15:36>select*fromt;+——+|id|+——+|1||2|+——+2rowsinset(0.00sec)
模擬誤操作：
dbadmin@test11:15:41>truncatetablet; QueryOK,0rowsaffected(0.01sec) dbadmin@test11:16:14>select*fromt; Emptyset(0.00sec)
模擬恢復操作：
step 1：找到誤操作的log position
dbadmin@test11:20:57>showmasterlogs; dbadmin@(none)11:21:37>showbinlogeventsin‘mysql-bin.000004’;
查看可以看到是444。
step 2：恢復到備份
dbadmin@test11:16:25>sourcetest.sql dbadmin@test11:17:26>selectfromt; +——-+ |id| +——-+ |1| +——-+ 1rowinset(0.00sec)
step 3: 因為我們在備份的時候使用了master-data的參數，所以可以直接看到備份時候的最后位置，然后應用中間的log。查看可以看到是187。
我們使用mysqlbinlog得到這一段時間的操作，其實我們也可以用這個工具得到操作后使用sed進行undo的操作。
mysqlbinlog–start-position=187–stop-position=444mysql-bin.000004>increment.sql dbadmin@test11:44:37>source/u01/my3307/log/increment.sqldbadmin@test11:44:50>selectfromt;+——+|id|+——+|1||2|+——+
至此數據恢復。
二、mysqlbackupmysqlbackup是Oracle公司提供的針對企業的備份軟件，全名叫做MySQL Enterprise Backup，是一個收費的軟件。
我們簡單來看一下這個工具的使用。
查看所有的幫助：
我這里只是截取了一小部分，這個幫助很長，參數很多，功能很全，是oracle官方主推的備份方式。
全量備份
mysqlbackup–user=root–password=ucjmh–databases=’t1′–encrypt-password=1–with-timestamp–backup-dir=/u01/backup/backup
解釋一下參數：
- databases 要備份的數據庫
- with-timestamp 產生一個當前時間的備份目錄。mysqlbackup這個工具要求一個空目錄才能做備份。所以這個會常用。
- backup-dir 備份的目錄 。
- compress：壓縮備份 這個提供了多種壓縮方法和壓縮級別。1–9,壓縮比依次遞增。
backup 是備份的方式， 一共有如下幾種方式，我會在一個恢復案例里把常用的幾個都用到。
Backupoperations:backup,backup-and-apply-log,backup-to-image Updateoperations:apply-log,apply-incremental-backup Restoreoperations:copy-back,copy-back-and-apply-log Validationoperation:validate Single-filebackupoperations:image-to-backup-dir,backup-dir-to-image,list-image,extract
其實，在大多數情況下,單個文件備份,使用backup-to-image命令創建,性能優于backup。buckup這個命令只執行一個完整的備份過程的初始階段。需要通過再次運行mysqlbackup運用apply-log 命令，使備份一致。
mysqlbackup–user=root–password=ucjmh–databases=’t1′–encrypt-password=1–with-timestamp–backup-dir=/u01/backup/2017-04-28_12-49-35/apply-log
當然你可以直接用backup-and-apply-log 不過這個時候的備份將不能用于增量了。
增量備份：
mysqlbackup–user=root–password=ucjmh–databases=’t1′–encrypt-password=1–with-timestamp–backup-dir=/u01/backup/–incremental–incremental-base=dir:/u01/backup/2017-04-28_12-49-35–incremental-backup-dir=/u01/backup/incrementalbackup
這個是基于上次的備份做的備份，當然也可以基于某一個log position之后做。
–incremental：代表增量備份；
–incremental-base：上次全備的目錄；
–incremental-backup-dir：增量備份的保存的目錄
大致梳理一下操作步驟，來了解一下恢復的原理：首先檢測并應用全備事務日志文件（這里是因為我備份的時候用的是backup而不是backup-and-apply-log），然后基于全備去應用增量的log。這個時候如果有多次增量備份也可以（基于LSN點向后應用）。 所有的都應用完成之后就是一個可以直接cp的數據庫了。
個人感覺這個工具比xtrabackup好用，但是xtrabackup是開源的，所以市場占有量才會大，才會更有名，更多人用吧。
三、mysqlhotcopymysqlhotcopy使用lock tables、flush tables和cp或scp來快速備份數據庫.它是備份數據庫或單個表最快的途徑,完全屬于物理備份,但只能用于備份MyISAM存儲引擎和ARCHIVE引擎，并且是一個服務器命令，只能運行在數據庫目錄所在的機器上.與mysqldump備份不同,mysqldump屬于邏輯備份,備份時是執行的sql語句.使用mysqlhotcopy命令前需要要安裝相應的軟件依賴包. 因為這個功能很弱，我們只簡單的介紹一個怎么用：
備份一個庫
mysqlhotcopydb_name[/path/to/new_directory]
備份一張表
mysqlhotcopydb_name./table_name//path/to/new_directory
更詳細的使用可以使用perldoc mysqlhotcopy查看。
四、xtrabackup/innobackupexPercona XtraBackup是一款基于MySQL的熱備份的開源實用程序，它可以備份5.1到5.7版本上InnoDB,XtraDB,MyISAM存儲引擎的表， Xtrabackup有兩個主要的工具：xtrabackup、innobackupex 。
（1）xtrabackup只能備份InnoDB和XtraDB兩種數據表，而不能備份MyISAM數據表
（2）innobackupex則封裝了xtrabackup，是一個 封裝，所以能同時備份處理innodb和myisam，但在處理myisam時需要加一個讀鎖。
首先我們先來簡單的了解一下xtrabackup是怎么工作的。xtrabackup基于innodb的crash-recovery（實例恢復）功能，先copy innodb的物理文件（這個時候數據的一致性是無法滿足的），然后進行基于redo log進行恢復，達到數據的一致性。
我們還是簡單來看一下日常工作中具體的使用：
全備：
xtrabackup–backup–target-dir=/data/backup/base
可以先看到
在備份過程中,可以看到很多輸出顯示數據文件被復制,以及日志文件線程反復掃描日志文件和復制。
同樣的，它也輸出了當前的binlog filename和position，如果有gtid(同樣也會輸出) 可以用于搭建主從。最后一行一定會是你的lsn被copy的信息。 這是因為每次啟動備份，都會記錄170429 12:54:10 >> log scanned up to (1676085)），然后開始拷貝文件，一般來講數據庫越大拷貝文件是要花費越長的時間，所以說這期間一般情況都會有新的操作，所以說所有文件也可能記錄的并不是一個時間點的數據， 為了解決數據這個問題，XtraBackup 就會啟動一個后臺進程來每秒1次的觀測mysql的事務日志，直到備份結束。而且把事務日志中的改變記錄下來。我們知道事物日志是會重用的（redo log）,所以這個進程會把redolog寫到自己的日志文件xtrabackup_log，這個后臺監控進程會記錄所有的事務日志的改變，用于保證數據一致性所。
增量備份：
當我們做過全量備份以后會在目錄下產生xtrabackup_checkpoints的文件 這里面記錄了lsn和備份方式，我們可以基于這次的全量做增量的備份。
$catxtrabackup_checkpoints backup_type=full-backuped from_lsn=0 to_lsn=1676085 last_lsn=1676085 compact=0 recover_binlog_info=0 xtrabackup–backup–target-dir=/data/backup/inc1–incremental-basedir=/data/backup/base
這個時候xtrabackup也是去打開了xtrabackup_checkpoints文件進行上一次備份的信息查看。這個時候去查看增量備份的xtrabackup_checkpoints也記錄了這些信息。
$cat xtrabackup_checkpoints backup_type = incremental from_lsn = 1676085 to_lsn = 1676085 last_lsn = 1676085 compact = 0 recover_binlog_info = 0
這也意味著你可以在增量的備份上繼續增量的備份。
同樣的，xtrabackup也支持壓縮（–compress）、加密（–encrypt）、并行(–parallel)等操作，但是和mysqlbackup不同的是這個沒有同時的備份binlog,而mysqlbackup是備份了binlog的。
我們來模擬一個恢復的過程深入的了解一下原理。
查看當前數據：
dbadmin@test03:04:33>selectfromt; +——-+ |id| +——-+ |1| +——-+ 1rowinset(0.00sec)
全量備份
$xtrabackup–backup–target-dir=/data/backup/base
模擬增量數據
dbadmin@test03:07:16>selectfromt; +——-+ |id| +——-+ |1| |2| +——-+ 2rowsinset(0.00sec)
進行增量備份：
$xtrabackup–backup–target-dir=/data/backup/inc1–incremental-basedir=/data/backup/base
模擬無備份操作：
dbadmin@test03:09:42>select*fromt; +——-+ |id| +——-+ |1| |2| |3| +——-+ 3rowsinset(0.00sec) 模擬誤操作：
dbadmin@test03:09:45>truncatetablet;QueryOK,0rowsaffected(0.00sec)
模擬恢復操作：
step 1：找到誤操作的log position
dbadmin@test03:10:19>showmasterlogs; dbadmin@test03:10:47>showbinlogeventsin‘mysql-bin.000001’; 1333
我們需要分別對全量、增量備份各做一次prepare操作。
增量
如果我們使用它自帶的還原命令的時候就要先把data目錄給清空。不然就會報如下的錯誤
$innobackupex–copy-back/data/backup/base/ 17042915:37:19innobackupex:Startingthecopy-backoperation IMPORTANT:Pleasecheckthatthecopy-backruncompletessuccessfully. Attheendofasuccessfulcopy-backruninnobackupexprints“completedOK!”. innobackupexversion2.4.6basedonMySQLserver5.7.13Linux(x86_64)(revisionid:8ec05b7)Originaldatadirectory/u01/my3307/dataisnotempty!
當然我們大多數據時候是不會在原來的實例上做操作的，都會把相應的備份在奇他的實例上進行恢復，然后再導出導入到誤操作的實例。這里我們直接清掉目錄，然后再次運行，查看恢復后的數據：
dbadmin@test03:41:56>select*fromt; +——-+ |id| +——-+ |1| |2| +——-+ 2rowsinset(0.00sec)
同樣的被恢復的目錄里會多出來兩個文件，一個是xtrabackup_binlog_pos_innodb，一個是xtrabackup_info。在這兩個文件中都可以看到你最后的log,pos。在info里還可以看到lsn。我們基于這個pos再進行binlog的重演，恢復在binlog沒有被備份的數據。
1076 $mysqlbinlogmysql-bin.000001–start-position=1076–stop-position=1333-vv>increment.sql dbadmin@test03:51:25>source/u01/my3307/log/increment.sqldbadmin@test03:51:34>select*fromt; +——-+ |id| +——-+ |1| |2| |3| +——-+ 3rowsinset(0.00sec)
至此數據恢復完成。
五、直接復制整個數據庫目錄MySQL還有一種非常簡單的備份方法，就是將MySQL中的數據庫文件直接復制出來。這是最簡單，速度最快的方法。 不過在此之前，要先將服務器停止，這樣才可以保證在復制期間數據庫的數據不會發生變化。如果在復制數據庫的過程中還有數據寫入，就會造成數據不一致。這種情況在開發環境可以，但是在生產環境中很難允許備份服務器。
注意：這種方法不適用于InnoDB存儲引擎的表，而對于MyISAM存儲引擎的表很方便。同時，還原時MySQL的版本最好相同。 只所以提這一點是因為當有停機窗口時，搭建主從的時候，這個往往是最快的。
一般生產環境的備份都會用percona-xtrabackup或者mysqlbackup，結合自己的情況，選擇合適的備份策略，適時拿出來驗證備份的有效性。
