RDS中的MYSQL備份恢複

RDS使用mysqldump對 MySQL 數據庫進行邏輯全量備份，使用開源軟件Xtrabackup進行物理全量備份，是實例級別的備份。

用戶登錄RDS控製台，可以下載備份文件。按照利用邏輯備份文件恢複到自建數據庫-MySQL和利用物理備份文件恢複到自建數據庫-MySQL中的操作步驟，實現數據的恢複。

本文主要從原理的角度來介紹MySQL數據庫的備份和恢複，希望能讓用戶更加了解RDS的備份恢複機製。

一、備份類型介紹

1. 按備份操作方式：物理備份和邏輯備份

備份方式	優點	缺點
邏輯備份	1. 邏輯備份是可以用編譯器或像grep和sed之類的命令查看和操作的普通文件；2. 恢複簡單，非常靈活；3. 與存儲引擎無關。	1. 還原時需要mysql加載和解釋語句，轉化為存儲格式，並重建索引，所以會比較慢；2. 無法保證導出後再還原出來的一定是同樣的數據。浮點數、軟件BUG等都會導致問題；3. 必須由數據庫服務器完成生成邏輯備份的工作，因此要使用更多的CPU周期。
物理備份	1. 基於文件的物理備份，隻需要將需要的文件複製到其他地方即可完成備份；2. 恢複更簡單；3. 恢複快，因為MySQL服務器不需要執行任何SQL或構建索引。	1. InnoDB的原始文件通常比相應的邏輯備份要大得多；2. 物理備份不總是可以跨平台、操作係統及MySQL版本。文件名大小寫敏感和浮點格式可能會遇到麻煩。

2. 按是否備份全部數據：完全備份和增量備份

完全備份：備份全部需要備份的數據

增量備份：僅備份上次完全備份或增量備份以後變化的數據

二、使用Mysqldump進行邏輯備份恢複

1. 備份數據庫

mysqldump作為重要的MySQL備份工具，功能相當強大。備份參數、恢複策略，需要仔細研究。

（1）基本語法

備份單個數據庫或單個數據庫中的指定表：

mysqldump [OPTIONS] database [tb1] [tb2]…

備份多個數據庫：

mysqldump [OPTIONS] –databases [OPTIONS] DB1 [DB2 DB3...]

備份所有數據庫：

mysqldump [OPTIONS] –all-databases [OPTIONS]

（2）選項[OPTIONS]說明

–default-character-set=charset

指定導出數據時采用何種字符集，如果數據表不是采用默認的 latin1 字符集的話，那麼導出時必須指定該選項，否則再次導入數據後將產生亂碼問題。

–lock-all-tables，-x

在開始導出之前，提交請求鎖定所有數據庫中的所有表，以保證數據的一致性。這是一個全局讀鎖，並且自動關閉 –single-transaction 和 –lock-tables 選項。

–lock-tables

和 –lock-all-tables 類似，不過是鎖定當前導出的數據表，而不是鎖定全部庫下的表。本選項隻適用於 MyISAM 表，如果是 Innodb 表可以用 –single-transaction 選項。

–no-create-info，-t

隻導出數據，而不添加 CREATE TABLE 語句。

–no-data, -d

隻導出數據庫表結構，不導出任何數據。

–opt

這隻是一個快捷選項，等同於同時添加 –add-drop-tables –add-locking –create-option –disable-keys –extended-insert –lock-tables –quick –set-charset 選項。本選項能讓 mysqldump 很快的導出數據，並且導出的數據能很快導回。該選項默認開啟，但可以用 –skip-opt 禁用。注意，如果運行 mysqldump 沒有指定 –quick 或 –opt 選項，則會將整個結果集放在內存中。如果導出大數據庫的話可能會出現問題。

–quick，-q

該選項在導出大表時很有用，它強製 mysqldump 從服務器查詢取得記錄直接輸出而不是取得所有記錄後將它們緩存到內存中。

–routines，-R

導出存儲過程以及自定義函數。

–single-transaction

該選項在導出數據之前提交一個 BEGIN SQL語句，BEGIN 不會阻塞任何應用程序且能保證導出時數據庫的一致性狀態。它隻適用於事務表，例如 InnoDB 和 BDB。

本選項和 –lock-tables 選項是互斥的，因為 LOCK TABLES 會使任何掛起的事務隱含提交。
要想導出大表的話，應結合使用 –quick 選項。

–triggers

同時導出觸發器。該選項默認啟用，用 –skip-triggers 禁用它。

2．恢複數據庫

RDS實現的是實例級別的邏輯備份，可以發現解壓出來的都是實例裏麵各個數據庫的sql文件。再執行數據庫的導入操作：

mysql -hhostname -uusername -ppassword databasename < backupfile.sql

三、使用Xtrabackup進行物理備份恢複

Xtrabackup是由percona提供的mysql數據庫備份工具，據官方介紹，這也是世界上惟一一款開源的能夠對innodb和xtradb數據庫進行熱備的工具。特點：

（1）備份過程快速、可靠；

（2）備份過程不會打斷正在執行的事務；

（3）能夠基於壓縮等功能節約磁盤空間和流量；

（4）自動實現備份檢驗；

（5）還原速度快；

Xtrabackup中主要包含兩個工具：

xtrabackup：是用於熱備份innodb, xtradb表中數據的工具，不能備份其他類型的表，也不能備份數據表結構；

innobackupex：是將xtrabackup進行封裝的perl腳本，可以備份和恢複MyISAM表以及數據表結構。

1.innobackupex工作原理

官方文檔：https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/how_innobackupex_works.html

備份 

如果在程序啟動階段未指定模式，innobackupex將會默認以備份模式啟動。

默認情況下，此腳本以–suspend-at-end選項啟動xtrabackup，然後xtrabackup程序開始拷貝InnoDB數據文件。當xtrabackup程序執行結束，innobackupex將會發現xtrabackup創建了xtrabackupsuspended2文件，然後執行FLUSH TABLES WITH READ LOCK，此語句對所有的數據庫表加讀鎖，然後開始拷貝其他類型的文件。

如果–ibbackup未指定，innobackupex將會自行嚐試確定使用的xtrabackup的binary。其確定binary的邏輯如下：首先判斷備份目錄中xtrabackup_binary文件是否存在，如果存在，此腳本將會依據此文件確定使用的xtrabackup binary。否則，腳本將會嚐試連接database server，通過server版本確定binary。如果連接無法建立，xtrabackup將會失敗，需要自行指定binary文件。

在binary被確定後，將會檢查到數據庫server的連接是否可以建立。其執行邏輯是：建立連接、執行query、關閉連接。若一切正常，xtrabackup將以子進程的方式啟動。

FLUSH TABLES WITH READ LOCK是為了備份MyISAM和其他非InnoDB類型的表，此語句在xtrabackup已經備份InnoDB數據和日誌文件後執行。在這之後，將會備份 .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, and .opt 類型的文件。

當所有上述文件備份完成後，innobackupex腳本將會恢複xtrabackup的執行，等待其備份上述邏輯執行過程中生成的事務日誌文件。接下來，表被解鎖，slave被啟動，到server的連接被關閉。接下來，腳本會刪掉xtrabackupsuspended2文件，允許xtrabackup進程退出。

恢複 

為了恢複一個備份，innobackupex需要以–copy-back選項啟動。

innobackupex將會首先通過my.cnf文件讀取如下變量：datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir，並確定這些目錄存在。

接下來，此腳本將會首先拷貝MyISAM表、索引文件、其他類型的文件（如：.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par and .opt files），接下來拷貝InnoDB表數據文件，最後拷貝日誌文件。拷貝執行時將會保留文件屬性，在使用備份文件啟動MySQL前，可能需要更改文件的owener（如從拷貝文件的user更改到mysql用戶）。

2. 使用innobackupex備份數據庫

（1）完全備份：

innobackupex –user=root -p /home/backup/

備份後的文件：在備份的同時，備份數據會在備份目錄下創建一個以當前日期時間為名字的目錄存放備份文件。