備份與恢復概述,冷備,熱備

對於DBA來講，最基本的工做就是數據庫的備份與恢復，在乎外狀況下（如服務器宕機、磁盤損壞等）要保證數據不丟失，或者是最小程度地丟失。每一個DBA應該每時每刻都關心本身所負責的數據庫的備份狀況。MySQL數據庫提供的大多數工具（如mysqldump、ibbackup、replication）都能很好地完成備份的工做，固然也能夠經過第三方的一些工具來完成，如xtrabackup、LVM快照備份等。DBA應該根據本身的業務要求設計出損失最小、對數據庫影響最小的備份策略。

備份與恢復概述

根據備份的方法能夠分爲：

1. Hot Backup（熱備）
2. Cold Backup（冷備）
3. Warm Backup（溫備）

Hot Backup是指在數據庫運行中直接備份，對正在運行的數據庫沒有任何影響。這種方式在MySQL官方手冊中稱爲Online Backup（在線備份）。Cold Backup是指在數據庫中止的狀況下進行備份，這種備份最爲簡單，通常只須要拷貝相關的數據庫物理文件便可。這種方式在MySQL官方手冊中稱爲Offline Backup（離線備份）。Warm Backup備份一樣是在數據庫運行時進行，可是會對當前數據庫的操做有所影響，例如加一個全局讀鎖以保證備份數據的一致性。

若是按照備份後文件的內容，又能夠分爲：

1. 邏輯備份
2. 裸文件備份

在MySQL數據庫中，邏輯備份是指備份後的文件內容是可讀的，一般是文本文件，內容通常是SQL語句，或者是表內的實際數據，如mysqldump和SELECT * INTO OUTFILE的方法。這類方法的好處是能夠看到導出文件的內容，通常適用於數據庫的升級、遷移等工做，可是恢復所須要的時間每每較長。

裸文件備份是指拷貝數據庫的物理文件，數據庫既能夠處於運行狀態（如ibbackup、xtrabackup這類工具），也能夠處於中止狀態。這類備份的恢復時間每每較邏輯備份短不少。

若按照備份數據庫的內容來分，又能夠分爲：

1. 徹底備份
2. 增量備份
3. 日誌備份

徹底備份是指對數據庫進行一個完整的備份。增量備份是指在上次的徹底備份基礎上，對更新的數據進行備份。日誌備份主要是指對MySQL數據庫二進制日誌的備份，經過對一個徹底備份進行二進制日誌的重作來完成數據庫的point-in-time的恢復工做。MySQL數據庫複製（Replication）的原理就是異步實時進行二進制日誌重作。

對於MySQL數據庫來講，官方沒有提供真正的增量備份的方法，大部分是經過二進制日誌來實現的。這種方法與真正的增量備份相比，效率仍是很低的。假設有一個100G的數據庫，若是經過二進制日誌來完成備份，可能同一個頁須要屢次執行SQL語句來完成重作的工做。可是對於真正的增量備份來講，只須要記錄當前每一個頁最後的檢查點的LSN。若是大於以前徹底備份時的LSN，則備份該頁，不然不用備份。這大大加快了備份的速度以及縮短了恢復的時間，同時這也是xtrabackup工具增量備份的原理。

此外，還須要理解數據庫備份的一致性，這要求在備份的時候數據在這一時間點上是一致的。舉例來講，在一個網絡遊戲中有一個玩家購買了道具，這個事務的過程是：先扣除相應的金錢，而後往其裝備表中插入道具，確保扣費和獲得的道具是互相一致的。不然，在恢復時，可能出現金錢被扣除了，可是裝備丟失的狀況。

對於InnoDB存儲引擎來講，由於其支持MVCC(多版本控制)功能，所以實現備份一致比較容易。能夠先開啓一個事務，而後導出一組相關的表，最後提交。固然，事務隔離級別必須是REPEATABLE READ的，這樣的作法就能夠給你一個完美的一致性備份。然而，這個方法的前提是須要你正確地設計應用程序。上述購買道具的過程不能夠分爲兩個事務來完成，如一個完成扣費，一個完成道具的購買。若備份發生在這二者之間，則會由於邏輯設計的問題致使備份出的數據依然是不一致的。

對於mysqldump備份工具來講，能夠經過添加-single-transaction選項來得到InnoDB存儲引擎的一致性備份，這時的備份是在一個執行時間很長的事務中完成的。另外，對於InnoDB存儲引擎的備份，要務必加上-single-transaction的選項（雖然是mysqldump的一個可選選項）。

冷備

對InnoDB存儲引擎的冷備很是簡單，只須要備份MySQL數據庫的frm文件、共享表空間文件、獨立表空間文件（*.ibd）、重作日誌文件。另外，按期備份MySQL數據庫的配置文件my.cnf，這樣有利於恢復操做。

一般，DBA會寫一個腳原本執行冷備的操做，DBA可能還會對備份完的數據庫進行打包和壓縮，這並非一件難事。關鍵在於，不要遺漏本來須要備份的物理文件，如共享表空間和重作日誌文件，少了這些文件數據庫可能都沒法啓動。另一種常常發生的狀況是，因爲磁盤空間已滿而致使的備份失敗，DBA可能習慣性地認爲運行腳本的備份是沒有問題的，少了檢驗的機制。

在同一臺機器上對數據庫進行冷備是遠遠不夠的，還須要將本地的備份放入一臺遠程服務器中，以確保不會由於本地數據庫宕機而影響備份文件的使用。

冷備的優勢是：

1. 備份簡單，只要拷貝相關文件便可。
2. 備份文件易於在不一樣操做系統、不一樣MySQL版本上進行恢復。
3. 恢復至關簡單，只須要把文件恢復到指定位置便可。
4. 恢復速度快，不須要執行任何SQL語句，也不須要重建索引。

冷備的缺點是：

1. InnoDB存儲引擎冷備的文件一般比邏輯文件大不少，由於表空間中存放着不少其餘數據，如Undo段、插入緩衝等信息。
2. 冷備並不老是能夠輕易地跨平臺。操做系統、MySQL的版本、文件大小寫敏感和浮點數格式都會成爲問題。

熱備

ibbackup

ibbackup是InnoDB存儲引擎官方提供的熱備工具，能夠同時備份MyISAM存儲引擎表和InnoDB存儲引擎表。

InnoDB存儲引擎表的備份工做原理以下：

1. 記錄備份開始時，InnoDB存儲引擎重作日誌文件檢查點的LSN。
2. 拷貝共享表空間文件以及獨立表空間文件。
3. 記錄拷貝完表空間文件後，InnoDB存儲引擎重作日誌文件檢查點的LSN。
4. 拷貝在備份時產生的重作日誌。

對於事務型的數據庫，如SQL Server數據庫、Oracle數據庫，熱備的原理與上述大體相同。能夠發現，在備份期間不會對數據庫自己有任何影響，所作的操做只是拷貝數據庫文件，所以任何對數據庫的操做都是容許的，不會出現阻塞狀況。

所以，ibbackup的優勢以下：

1. 在線備份。不阻塞任何SQL語句。
2. 備份性能好。備份的實質是複製數據庫文件和重作日誌文件。
3. 支持壓縮備份。經過選項，能夠支持不一樣級別的壓縮。
4. 跨平臺支持。ibbackup能夠運行在Linux、Windows以及主流的Unix系統平臺上。

ibbackup對InnoDB存儲引擎表的恢復過程以下：

1. 恢復表空間文件。
2. 應用重作日誌文件恢復InnoDB存儲引擎表。

ibbackup提供了一種高性能的熱備方式，是InnoDB存儲引擎備份的首選方式。不過它是收費軟件，好在Pecona公司給咱們帶來了開源、免費的XtraBackup熱備工具，它能夠實現ibbackup的全部功能，而且還擴展支持真正的增量備份功能。所以，更好的選擇應該是使用XtraBackup來完成熱備的工做。

XtraBackup

XtraBackup支持MySQL數據庫5.0版和5.1版，同時也支持InnoDB Plugin版本新增的Barracuda頁格式。XtraBackup在GPL v2開源協議下發布，官方網站地址是：https：//launchpad.net/percona-xtrabackup。

xtrabackup命令的使用方法以下：

xtrabackup --backup|--prepare [OPTIONS]

xtrabackup命令的可選參數以下所示：

(The defaults options should be given as the first argument)

--print-defaults Prints the program's argument list and exit.

--no-defaults Don't read the default options from any file.

--defaults-file=Read the default options from this file.

--defaults-extra-file=Read this file after the global options files have been read.

--target-dir=The destination directory for backups.

--backup Make a backup of a mysql instance.

--stats Calculate the statistic of the datadir（it is recommended you take mysqld offline）.

--prepare Prepare a backup so you can start mysql server with your restore.

--export Create files to import to another database after it has been prepared.

--print-param Print the parameters of mysqld that you will need for a for copyback.

--use-memory=This value is used instead of buffer_pool_size.

--suspend-at-end Creates a file called xtrabackup_suspended and waits until the user deletes that file at the end of the backup.

--throttle=（use with--backup）Limits the IO operations（pairs of reads and writes） per second to the values set here.

--log-stream outputs the contents of the xtrabackup_logfile to stdout.

--incremental-lsn=（use with--backup）Copy only.ibd pages newer than the specified LSN high：low. 

##ATTENTION##：checkpoint lsn*must*be used.Be Careful！

--incremental-basedir=（use with--backup）Copy only.ibd pages newer than the existing backup at the specified directory.

--incremental-dir=（use with--prepare）Apply.delta files and logfiles located in the specified directory.

--tables=name Regular Expression list of table names to be backed up.

--create-ib-logfile（NOT CURRENTLY IMPLEMENTED）will create ib_logfile* after a--prepare.

###If you want to create ib_logfile*only re-execute this command using the same options.###

--datadir=name Path to the database root.

--tmpdir=name Path for temporary files.Several paths may be specified as a colon（：）separated string.

If you specify multiple paths they are used round-robin.

若是咱們要作一個徹底備份，能夠執行以下命令：

./xtrabackup --backup

./xtrabackup Ver alpha-0.2 for 5.0.75 unknown-linux-gnu（x86_64）

＞＞log scanned up to（0 1009910580）

............................................................................................................................

............................................................................................................................

Copying./tpcc/customer.ibd

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/customer.ibd

＞＞log scanned up to（0 1010561109）

……done

Copying./tpcc/district.ibd

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/

tpcc/district.ibd

……done

............................................................................................................................

............................................................................................................................

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/

tpcc/warehouse.ibd

……done

＞＞log scanned up to（0 1014592707）

Stopping log copying thread..

Transaction log of lsn（0 1009910580）to（0 1014592707）was copied.

XtraBackup實現增量備份

MySQL數據庫自己提供的工具並不支持真正的增量備份，更準確地說，二進制日誌的恢復應該是point-in-time的恢復而不是增量備份。XtraBackup工具支持對InnoDB存儲引擎的增量備份，其工做原理以下：

（1）首先完成一個徹底備份，並記錄下此時檢查點的LSN。

（2）在進行增量備份時，比較表空間中每一個頁的LSN是否大於上次備份時的LSN，若是是，則備份該頁，同時記錄當前檢查點的LSN。

所以XtraBackup的備份和恢復過程大體以下：

（full backup）

#./xtrabackup --backup --target -dir=/backup/base

（incremental backup）

#./xtrabackup --backup --target -dir=/backup/delta --incremental -basedir=/backup/base

（prepare）

#./xtrabackup --prepare --target -dir=/backup/base

（apply incremental backup）

#./xtrabackup --prepare --target -dir=/backup/base --incremental -dir=/backup/delta

上述過程當中，首先將所有文件備份到/backup/base目錄下，增量備份產生的文件備份到/backup/delta。恢復過程當中，首先指定徹底備份的路徑，而後將增量備份應用於該徹底備份。如下顯示了一個完整的增量備份過程：

./xtrabackup --backup

＞＞log scanned up to（0 378161500）

The latest check point（for incremental）：'0：377883685'＜=====使用這個LSN

＞＞log scanned up to（0 379294296）

Stopping log copying thread..

Transaction log of lsn（0 377883685）to（0 379294296）was copied.

（must do--prepare before the each incremental backup）

./xtrabackup --prepare

./xtrabackup --backup --incremental=0:377883685

incremental backup from 0：377883685 is enabled.

＞＞log scanned up to（0 379708047）

Copying./ibdata1

to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/

tmp_diff/ibdata1.delta

……done

The latest check point（for incremental）：'0:379438233'＜====下一個增量備份開始的LSN

＞＞log scanned up to（0 380663549）

Stopping log copying thread..

Transaction log of lsn（0 379438233）to（0 380663549）was copied.