MariaDB直到5.5版本，都一直依照MySQL的版本，所以，使用MariaDB5.5即可瞭解到MySQL5.5的所有功能，而 MariaDB並沒有所謂的5.6版本，而是直接將5.5之後的版本定義爲MariaDB 10.0，MariaDB 10.0是建立在MariaDB5.5的基礎上的，並且它擁有MySQL5.6的補丁功能以及一些其他的新特性。
1. 備份種類
1.1 全量備份（Full Backup）
全量備份也叫完全備份，全量備份就是對某個時間點的所有數據進行一個完全的備份，對應時間點的所有數據都被包含在完全備份中。
1.2 差異備份（Differential Backup）
差異備份也叫差量備份，“差異備份"是對上一次"全量備份"以後變化的數據的備份，比如，這週日2點對數據庫進行了"全量備 份”，當下週一對數據庫做差異備份時，將會備份從週日2點以後到週一差異備份時期間的所有變化的數據，如果下週二對數據庫進行差異備份，則會備份從週日2 點以後到週二差異備份時期間的所有變化的數據，同理，如果下週三對數據庫進行差異備份，下週三的差異備份將會包含週日2點以後到週三差異備份之時期間的所 有變化的數據，如果只在週日2點做了一次完全備份，之後再也沒有進行過完全備份，都是通過差異備份的方式進行備份，那麼當需要通 過備份將數據還原到最近的時間點時，只要擁有周日的完全備份與最近一次的差異備份即可，中間的差異備份時不需要的。說白了，每次差異備份都是針對上一次" 完全備份"之後的變化數據進行的。
1.3 增量備份（Incremental Backup ）
“增量備份"是對上一次"備份"以後變化的數據的備份。“差量備份"與"增量備份"唯一的區別就是備份的” 起始參考點"不同，“差異備份"的起始點是最近一次的"全量備份”，“增量備份"的起始點是最近的上一次的"備份”，不管上一次"備份"是"全量備 份”、“差異備份” 還是 “增量備份”。如果進行增量備份，備份的數據就是上一次備份以後產生變化的數據。
1.4 時間點恢復
全量備份、差異備份、增量備份，都不能解決時間點恢復。假設，週日2點進行了全量備份，想要在下週一2點進行第二次備份，但是如果在週一2點之前，數據庫崩潰了，需要還原，該怎麼辦呢？如果 只依靠週日2點的備份進行還原，那麼最多隻能將數據恢復到週日2點時的樣子，但是週日2點以後的所有數據變化都會丟失，因爲並沒有來得及對2點以 後的數據進行備份，可以通過二進制日誌解決這個問題。因爲所有數據變化都會被記錄到二進制日誌中，所以，可以先通過備份將數據還原到週日2點，然後再通過二進制日誌，將2點以後的操作"重放"一 遍，數據就恢復到了崩潰之前的樣子，這就是時間點恢復的概念，也就是說，在實際的還原數據的工作中，如果想要完整的還原數據，往往需要數據備份文件以及二進制日誌文件，二者缺一不可。
1.5 熱備
在數據庫正常運行的情況下進行備份，也就是說，在熱備期間，數據庫的讀寫操作均可正常進行，所以，熱備份不能只依靠簡單的拷貝命令，而是需要專門的備份工具，而且技術複雜程度較高，mysql中的myisam存儲引擎不支持熱備，InnoDB存儲引擎支持熱備。
1.6 溫備
溫備比熱備稍弱一點，在溫備期間，數據庫只能進行讀操作，不能進行寫操作，即數據庫在可讀但不可寫的狀態下進行備份。
1.7 冷備
讀寫操作均不可進行的狀態下所做的備份被稱爲冷備。冷備雖然會影響數據庫的運行，但是備份出的數據的可靠性是最高的，冷備的備份過程往往是最簡單的，mysql中，可通過複製結構去做冷備。
1.8 物理備份
物理備份就是直接備份數據庫所對應的數據文件，以達到備份的目的，物理備份相對邏輯備份來說，性能更強。
1.9 邏輯備份
邏輯備份就是將數據從數據庫中導出，並將導出的數據進行存檔備份，這種備份方式被稱作邏輯備份。
2. 備份工具
2.1 mysqldump
mysqldump是mysql自帶的邏輯備份工具。通過協議連接到mysql數據庫，將需要備份的數據查詢出來，將查詢出的數據轉換成對應的insert語句，當需要還原這些數據時，只要執行這些insert語句，即可將對應的數據還原。
2.1.1 mysqldump的優點
可以直接使用文本處理工具處理對應的備份數據，因爲備份數據已經被mysqldump轉換爲了對應的insert語句，所以，可以藉助文件系統中的文本處理工具對備份數據進行直接處理。
2.1.2 mysqldump的缺點：
當數據爲浮點類型時，會出現精度丟失。
mysqldump的備份過程屬於邏輯備份，備份速度、恢復速度與物理備份工具相比較慢，而且mysqldump備份的過程是串行化的，不會並行的進行備份，如果想要並行備份，可以使用mydumper，但是此處不考慮這些，只考慮mysqldump，當數據量較大時，一般不會使用 mysqldump進行備份，因爲效率較低。
mysqldump對innodb存儲引擎支持熱備，innodb支持事務，可以基於事務通過mysqldump對數據庫進行熱備。
mysqldump對myisam存儲引擎只支持溫備，通過mysqldump對使用myisam存儲引擎的表進行備份時，最多隻能實現溫備，因爲在備份時會對備份的表請求鎖，當備份完成後，鎖會被釋放。
2.1.3 mysqldump使用
輸出的信息中包含一些註釋，這些註釋信息中包括mysqldump的版本，mysql的版本，以及主機IP，數據庫信息等信息。
/*!40101 SET NAMES utf8 */;
那麼上述信息有什麼用呢？來了解一下，因爲，mysqldump備份出的信息爲可執行的sql，所以，當使用這些sql進行數據還原的時 候，則必須執行它們，而上述信息表示當mysql版本大於等於4.01.01的時候，纔會執行 SET NAMES utf8這條語句，否則這條語句則不會被執行，如果使用mysqldump備份出的sql語句在其他關係型數據庫上執行，那麼這些信息將被當做註釋處理， 這是mysql爲了使這些sql語句的兼容性更強而使用的一種手段，不用過分在意他們。
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
| test1 |
+--------------------+
5 rows in set (0.00 sec)
MariaDB [test1]> show tables;
+-----------------+
| Tables_in_test1 |
+-----------------+
| t |
+-----------------+
1 row in set (0.00 sec)
[root@master mysql]# mysqldump -uroot -pblueice1980
Usage: mysqldump [OPTIONS] database [tables]
OR mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR mysqldump [OPTIONS] --all-databases [OPTIONS]
[root@master mysql]# chown mysql:mysql -R /var/lib/mysql
[root@master mysql]# mysqldump -uroot -pblueice1980 test t
-- MySQL dump 10.16 Distrib 10.2.31-MariaDB, for Linux (x86_64)
--
-- Host: localhost Database: test
-- ------------------------------------------------------
-- Server version 10.2.31-MariaDB-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
mysqldump: Couldn't find table: "t"
[root@master mysql]# mysqldump -uroot -pblueice1980 test1 t
-- MySQL dump 10.16 Distrib 10.2.31-MariaDB, for Linux (x86_64)
--
-- Host: localhost Database: test1
-- ------------------------------------------------------
-- Server version 10.2.31-MariaDB-log
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `t`
--
DROP TABLE IF EXISTS `t`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `t` (
`id` int(11) DEFAULT NULL,
`name` varchar(30) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `t`
--
LOCK TABLES `t` WRITE;
/*!40000 ALTER TABLE `t` DISABLE KEYS */;
INSERT INTO `t` VALUES (1,'222'),(2,'3333');
/*!40000 ALTER TABLE `t` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2020-03-29 10:24:19
sql腳本中並不包含任何創建數據庫的語句，只有創建表的語句，也就是說，在還原時，必須先確保對應的數據庫已經存 在，那麼，能不能再備份時就生成創建庫的語句呢？必須的額，使用–databases選項指定數據庫，即可在備份時生成創建數據庫的語句 。
[root@master mysql]# mysqldump -uroot -pblueice1980 test1 t --databases;
...........
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `test1` /*!40100 DEFAULT CHARACTER SET latin1 */;
...........
不會生成創建數據庫的語句，只是備份其中的表（包括創建表的語句和數據
mysqldump -uroot -h192.168.1.71 zsythink -p
只備份zsythink數據庫中的t1、t2、t3表，其他表不會備份，也不會生成創建zsythink數據庫的語句（但是對應的表的創建語句會生成，表數據會備份）
mysqldump -uroot -h192.168.1.71 zsythink t1 t2 t3 -p
句備份zsythink整個數據庫，包括其中的所有表，並且會生成創建zsythink數據庫的語句
mysqldump -uroot -h192.168.1.71 --databases zsythink -p
備份指定的多個數據庫，所有被指定的數據庫中的表都會被備份，對應的創建庫的語句也會生成，下例表示同時備份zsythink庫與test庫
mysqldump -uroot -h192.168.1.71 --databases zsythink test -p
備份當前數據庫服務中的所有庫
mysqldump -uroot -h192.168.1.71 --all-databases -p
只備份數據庫的表結構，不備份數據，不包含表數據，不包含創建庫的語句，只有創建表的語句，如下命令的"-d"選 項可使用"–no-data"代替，
mysqldump -uroot -hlocalhost -d zsythink -p
示備份zsythink數據庫中test表的表結構，不包含表數據，不包含創建庫的語句，只有創建test表的語句
mysqldump -uroot -hlocalhost -d zsythink test -p
2.1.4 mysqldump選項
–master-data
在實際進行數據恢復時，往往需要進行時間點還原，通常的做法是先通過最近一次的備份，將數據恢復到備份時的樣子，然後再通過二進制日誌， 將備份之後的更改操作重放一遍，這樣就將數據恢復成了最近的模樣，比如，備份開始時，二進制日誌對應的position爲123，那麼在進行時間點還 原時，則需要先通過"備份文件"將數據恢復爲備份時的樣子，然後再通過二進制日誌文件，將position 123之後的所有操作重放一遍。但是，在還原時，怎麼知道備份時position的值呢？沒錯，必須在備份時就做好標記，在恢復時才知道應該從哪 裏重放。否則在恢復時，則無法獲取到重放二進制日誌的起始點位置。
對於主從複製結構來說，數據庫已經運行了一段時間，裏面已 經存在了一些數據，要將數據庫架構從單機架構改爲主從架構，你想把當前的主機作爲主服務器，然後再新加入一臺服務器作爲從服務器，那麼，一般 的做法是將主庫中的數據先備份一份出來，然後導入到從庫中，但是，當你從主庫中備份數據時，往往是熱備的，也就是說，備份完成後，有一些操作只在主庫中完 成了，而備份中卻不存在這些數據，所以，使用備份在從庫中將數據還原以後，還要告訴"從庫"，將備份之後的操作從"主庫"那邊同步過來，但是，怎 麼知道從哪裏開始同步呢？沒錯，必須在備份的時候就記住它的position，以便告訴從庫，從哪裏開始同步。其實，這與手動重放二進制日誌時的 場景並沒有什麼不同，它們的最終目的都是要確定通過備份還原數據以後，要從哪個位置開始執行之後的"重放"或"同步"操作。
–master-data選項有3個可用值，0、 1 、2，這三個值分別表示不同的含義
此值爲0：表示在使用mysqldump進行備份時，不記錄對應二進制日誌文件位置，將此值顯式的設置爲0與不使用此選項的效果相同。
此值爲1：表示在使用mysqldump進行備份時，記錄對應二進制日誌文件位置，此值爲默認值，也就是說，使 用–master-data與使用–master-data=1的效果相同，如果將此選項的值設置爲1，則會在備份文件中生成對應的"CHANGE MASTER TO"語句，此語句中標明瞭備份開始時二進制日誌的前綴名以及其所處的position(位置)，生成此語句的目的是，在主從複製結構中的"從服務器"中 通過備份sql還原數據以後，告訴"從庫"，從"主庫"的二進制日誌文件中的哪個位置開始"同步"。如果沒有使用主從複製結構，同時又想要在備份時記 錄二進制日誌文件的position，則可以將此選項的值設置爲2。
此值爲2：表示在使用mysqldump進行備份時，記錄對應二進制日值文件的位置，如果將此選項的值設置爲 2，則會在備份文件中生成對應的"CHANGE MASTER TO"語句，此語句中標明瞭備份開始時二進制日誌的前綴名以及其所處的position(位置)，但是"CHANGE MASTER TO"語
–flush-logs
如果，將二進制日誌的大小設置爲600兆，那麼，每當二進制日誌的大小滿600兆，對應的二進制日誌文件就會發生滾 動，生成一個新的二進制文件，並將原來的600兆保存，假設，使用mysqldump對數據庫進行備份的那一刻，對應binlog的大小爲300兆， 也就是說，備份操作開始時，二進制日誌文件的position的位置則會處於文件居中的位置，那麼，當想要找到對應position進行重放時，此位 置之前的操作記錄對於來說都是"無用"的，可是比較尷尬的是，還必須找到此位置，這樣就會產生一些"多餘的工作量"，那麼能不能直接避免這種 情況的發生呢？必須的，勞動人民的智慧是無窮的，聰明如你一定想到了，使用一個選項就能搞定，沒錯，就是一個選項，它就是–flush-logs選項， 當使用mysqldump進行備份時，如果使用了此選項，備份開始時就會滾動一次二進制日誌，無論二進制日誌對應的文件大小是否達到600兆，都會滾動。
–routines選項：存儲過程和存儲函數也會被備份。
–triggers選項：觸發器會被備份。
–events選項：事件表會被備份。
2.1.5 基於innodb的mysqldump備份
所謂"基於事務"完成備份，就是說所有備份的操作都是在一個"獨立的事務"中完成的，而且這個事務的隔離級別爲"可重讀"，其他讀寫操作是在這個備份事務之外進行的，所以，利用"可重讀"事務的"隔離性"，即可保證讀寫操作並不會對備份操作造成影響。
在備份innodb存儲引擎的表時，如果想讓備份操作基於"獨立的事務"進行，則需要使用 --single-transaction選項。使用了–single-transaction選項，mysqldump會自動開啓一個"可重讀"的事務，基於這個獨立的"事務"，備份出一個滿足一致性的數據備份。
使用–single-stransaction選項備份後，查看general_log日誌。
開啓查詢日誌
select event_time,thread_id,command_type,argument from mysql.general_log;
從日誌中可以看到如下信息，mysqldump自動將備份會話中的事務隔離級別設置爲了"可重讀"，並且開啓了一個事務，而且，開始事務時，使用 了"WITH CONSISTENT SNAPSHOT"，表示事務開始的那一刻，同時創建了快照，以保證備份事務中的"一致性讀"。
如果開啓了二進制日誌，也要設置–master-data選項。
2.1.6 基於innodb的myisam備份
數據庫中的表使用了myisam存儲引擎，在備份時最多隻能達到溫備的程度，因爲myisam存儲引擎不支持事務，使用 --single-transaction選項對myisam表進行備份，也不起作用，只能通過鎖表的方式進行，即在備份開始到備份結束期間， 備份的表會被加上讀鎖，以保證數據的一致性，但是如果你的mysql環境是主從環境，則可以在從服務器上進行備份操作， 對myisam表進行備份時，需要加鎖以保證數據一致性即可。
對所有數據備份時，可以使用–lock-all-tables選項，對所有庫的所有表加讀鎖，–lock-all-tables對應的短選項爲-x，與–single-transaction選項不能同時存在。
mysqldump -uroot -h192.168.1.71 --lock-all-tables --all-databases -p > dbbackup.sql
對指定的數據庫進行備份時，可以使用–lock-tables選項，對指定庫的所有表加鎖，–lock-tables對應的短選項爲-l，與–single-transaction選項同時存在時，此選項將失效。
mysqldump -uroot -h192.168.1.71 --lock-tables --databases zsythink -p > zsythink.sql
也可以通過鎖表的方式對innodb存儲引擎的表進行備份，不過這樣就不是熱備了，而是溫備。
2.1.7 使用innodb存儲引擎時常用的備份語句
未開啓二進制日誌，備份指定的zsythink數據庫
mysqldump -uroot -h192.168.1.71 --single-transaction --routines --triggers --events --databases zsythink -p > zsythink.sql
開啓二進制日誌的情況下，備份指定的zsythink數據庫
mysqldump -uroot -h192.168.1.71 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --databases zsythink -p > zsythink.sql
開啓二進制日誌的情況下，備份所有數據庫
mysqldump -uroot -h192.168.1.71 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --all-databases -p > dbbackup.sql
2.1.8 使用myisam存儲引擎時常用的備份語句
未開啓二進制日誌，備份指定的zsythink數據庫
mysqldump -uroot -h192.168.1.71 --routines --triggers --events --lock-tables --databases zsythink -p > zsythink.sql
開啓二進制日誌的情況下，備份指定的zsythink數據庫
mysqldump -uroot -h192.168.1.71 --flush-logs --master-data=2 --routines --triggers --events --lock-tables --databases zsythink -p > zsythink.sql
在開啓二進制日誌的情況下，備份所有數據庫
mysqldump -uroot -h192.168.1.71 --flush-logs --master-data=2 --routines --triggers --events --lock-all-tables --all-databases -p > dbbackup.sql
2.1.9 使用mysqldump備份出的數據進行恢復
因爲恢復數據時會執行大量的insert語句，如果沒有特殊要求，還原時沒有必要將這些操作記錄到二進制日誌中，所以關閉當前會話的二進制日誌記錄。
set sql_log_bin=OFF;
所有恢復操作完成後，最好將當前會話中的sql_log_bin再次開啓。
通過mysqldump備份的出的zsythink數據庫的數據文件存放在/testdir目錄下，那麼，可以在mysql提示符中使用如下命令，執行對應的sql文件。
. /testdir/zsythink.sql
上述備份sql文件執行完畢後，zsythink數據庫已經恢復到了備份sql對應的時間點，如果不進行時間點恢復，那麼做到這一步就算完成了恢復工作，但是往往需要進行時間點還原。
進行時間點恢復時，備份時間點之後的數據則需要通過二進制日誌進行還原，首先，要從二進制日誌中提取對應的sql，提取sql的起始位置爲備份開始 時那一刻二進制文件對應的position，因爲在使用mysldump備份時，推薦使用–master-data=2選項，所以在對應的數據庫備 份sql文件中應該存在對應的position，提取sql的結束位置應該是drop語句對應的位置，因爲咱們模擬的場景是有人誤操作drop了數據庫， 所以結束位置應該是drop語句的位置。注意，不要把誤操作的drop語句提取出來，否則重放對應sql時又會將對應的數據刪除。
2.2 xtrabackup
percona公司是mysql領域比較有名的諮詢公司，這個公司對innoDB存儲引擎進行了性能增強，被percona增強後的innoDB存 儲引擎叫做Percona XtraDB，Centos7中默認提供Mariadb5.5數據庫，而MariadDB5.5的默認的存儲引擎就是XtraDB，因爲XtraDB完全兼容InnoDB，在MariadDB5.5中使用show engines命令查看存儲引擎時，會發現引擎的名稱爲InnoDB，但是對應的描述中，InnoDB卻被描述爲Percona-XtraDB，因爲兼 容，所以引擎名稱爲InnoDB，但是實際上使用的是Percona公司的XtraDB存儲引擎。
percona也有自己的mysql分支，叫做Percona Server for MySQL，percona出品數據庫備份工具XtraBackup是一款免費軟件，因此，它是商業備份工具InnoDB Hot Backup的一個很好的替代品。
與mysqldump不同，xtrabackup是一種物理備份工具，但是，它是需要通過協議連接到mysql服務端（這一點與mysqldump相同，它們都是客戶端工具，都需要連接到服務端），然後讀取並複製innodb底層的"數據塊"，完成所謂的"物理備份"。
innodb存儲引擎的邏輯結構如上圖所示，邏輯單元從大到小分別爲:表空間(tablesapce)、段(segment)、區(extent)、頁(page)、行(row)，如上圖所示，每個大的邏輯單元中都包含了N個小的邏輯單元。把上圖中Extent區域中的每個"小方塊(page)“當做 xtrabackup需要備份的"數據塊”，因爲數據存放於行中，行存在於page中，所以，備份對應page，即可備份出對應的數據，當使用 xtrabackup連接到mysql服務端的時候，xtrabackup會讀取innodb中的page。
每個Page都有自己的LSN號碼，LSN是一個全局遞增的號碼，每次對page中的記錄進行修改時，都會有對應的LSN號碼，因爲LSN是全局遞 增的，所以，LSN只會越來越大，之後的修改產生的LSN肯定比之前的操作產生的LSN大，每個page中的數據被更改時，都會在這個page中記錄下本 次的LSN號碼，所以，如果這個page中記錄的LSN越大，就證明這個Page中的數據越新（最近被修改）。而xtrabackup就是通過LSN，實現對innodb表的增量備份的，每次備份開始時，xtrabackup會記錄下當前備份到的LSN號 碼，當下次進行增量備份時，xtrabackup就只會拷貝出LSN大於上次記錄的page，那些LSN號碼小於上次記錄的page則會被跳過，如果 page中的LSN小於上次備份時記錄的LSN號碼，則證明這個page自從上次備份以來並沒有被修改過，同理，如果page中的LSN大於上次備份時記 錄的LSN號，則證明這個page在上次備份以後，已經被修改了，所以，備份出這些page，即可實現增量備份的目的。
當開始備份innodb數據時，還需要同時備份對應的事務日誌，因爲在開始備份時，有些事務已經存在於事務日誌中，這些事務可能已經提交 了，但是還沒有同步到datafile中，所以要重放這些已經提交的事務，有些事務可能還未提交，所以要回滾這些沒有提交的事務。
xtrabackup在備份開始時，同時運作兩個線程，一個線程負責備份innodb中的page，另一個線程負責備份innodb 的事務日誌（redo log），事務日誌都會被xtrabackup記錄到自己的日誌文件中，那麼，備份結束後，會得到兩份文件，一份是不可用的備份文件，一份是備份時的 事務日誌，備份文件之所以不可用，是因爲有一部分不確定的數據可能在事務日誌中，而且熱備過程中數據也可能會發生改變，所以要通過這兩份文件，製作出 一份可用的備份文件，沒錯，就是通過應用事務日誌的方式，讓最終的備份成爲一個可用的備份，事務日誌會被應用，事務日誌文件中已經提交的事務需要 replayed，未提交的事務需要roolback， 整個過程類似於mysql崩潰後恢復的過程，但是這個過程在xtrabackup中被稱爲"prepare"，"prepare"操作保證了 備份出的數據的一致性，沒有經過prepare的備份數據是不可用的，可以理解爲如果想要得到一個可用的備份，則需要進行這些所謂的"準備"工作或者 所謂的"數據恢復"的工作。
想要備份數據可用，則必須進行prepare工作，先不考慮存在增量備份的情況，當不存在 增量備份時，在對數據進行prepare時，需要應用事務日誌，對於已經寫入redologfile中但是還沒有寫入datafile中的已提交事務 進行同步，對於未提交的的事務所作出的修改進行回滾，這是沒有增量的情況下，但是，如果存在增量備份時，xtrabackup會將所有增量都合併到之前的 全量上，然後使用最後的完整數據進行還原，那麼，在合併數據的過程中，上一次未提交的事務有可能在下次的增量備份中已經提交了，所以，如果存在多個增量備 份的時候，在進行prepare工作時，只需要將已經提交的事務同步到數據文件中即可，未提交的事務不用進行回滾，因爲在增量中，這些事務可能已經提 交了，只需要在最後一份增量數據進行prepare時，將對應的未提交的事務回滾即可。
xtrabackup能對innodb做熱備，能對myisam做溫備，對myisam做溫備時會對myisam表添加讀鎖，也就是 說，備份出的myisam表中的數據應該是一致的 ，但是如果數據庫中既有myisam表又有innodb表時，如果想要整體的所有數據都一致，則只能以myisam的一致性時間點作爲最終備份的一致性時 間點，所以，xtrabackup在備份時，會先備份inndb數據，備份完innodb數據後，再備份非innodb數據，當需要將備份的數 據"prepare"時，只操作innodb數據即可，非innodb數據不用動，prepare完成後，innodb的一致性時間點與非innodb數 據的一致性時間點是相同的。
2.2.1 安裝Xtrabackup
安裝2.3版本之前的XtraBackup後，會得到兩個主要的備份工具：xtrabackup與innobackupex。xtrabackup是一個C程序。innobackupex是一個perl腳本，它對xtrabackup這個C程序進行了封裝，在備份innodb表時，此腳本會調用xtrabackup這個C程序。xtrabackup只能備份innodb和xtradb的表，不能備份myisam表。innobackupex可以備份innodb或xtradb的表，同時也能夠備份myisam表。所以，一般在使用XtraBackup備份工具進行數據備份時，通常會選擇使用innobackupex命令進行備份。
xtrabackup是一個C程序，innobackupex是一個perl腳本，當它們作爲兩個進程運行時，總是沒有特別完美的方式讓它們進行通訊，導致bug的出現，在2.3版本的XtraBackup，官方使用C重寫innobackupex，將它與 xtrabackup這個C程序完美的整合在一起。 爲了兼容之前用戶的使用習慣，官方保留了innobackupex，它作爲一個軟連接，指向了xtrabackup。
[root@master mysql]# yum search xtrabackup
Loaded plugins: fastestmirror
Bad id for repo: centos-paas-openshift-origin , byte = 28
Loading mirror speeds from cached hostfile
======================================================= N/S matched: xtrabackup =======================================================
holland-xtrabackup.noarch : Holland plugin for Percona XtraBackup
percona-xtrabackup-test.x86_64 : Test suite for Percona Xtrabackup
percona-xtrabackup.x86_64 : Online backup for InnoDB/XtraDB in MySQL, Percona Server and MariaDB
[root@master mysql]# yum info percona-xtrabackup
Loaded plugins: fastestmirror
Bad id for repo: centos-paas-openshift-origin , byte = 28
Loading mirror speeds from cached hostfile
Available Packages
Name : percona-xtrabackup
Arch : x86_64
Version : 2.3.6
Release : 1.el7
Size : 4.6 M
Repo : epel
Summary : Online backup for InnoDB/XtraDB in MySQL, Percona Server and MariaDB
URL : http://www.percona.com/software/percona-xtrabackup/
License : GPLv2
Description : Online backup for InnoDB/XtraDB in MySQL, MariaDB and Percona Server
2.2.2 備份準備工作
創建數據庫備份用戶bkupdbuser
CREATE USER 'bkupdbuser'@'192.168.1.71' IDENTIFIED BY '123123';
授予bkupdbuser用戶正常備份的最小權限
GRANT RELOAD,LOCK TABLES,REPLICATION CLIENT,PROCESS ON *.* TO 'bkupdbuser'@'192.168.1.71';
FLUSH PRIVILEGES;
2.2.3 xtrabackup全量備份及恢復
備份當前數據庫服務器上的所有數據庫，對所有數據庫進行全量備份，將備份的文件存放在/backup目錄下，–defaults-file選項指定了備份數據庫時
innobackupex --defaults-file=/etc/my.cnf --host=192.168.1.71 --user=root --password=123123 /backup
使用root用戶，備份本機上的數據庫，那麼–host選項與–user選項都可以省略，–password選項也可以替換爲對應的短選項-p，同時，如果使用默認的配置文件，–defaults-file選項也可以省略，xtrabackup自動在指定的備份目錄中創建了一個備份目錄，目錄名稱爲當前的日期與時間，同時，信息中還輸出了備份時二進制日誌處於 哪個二進制日誌文件中以及其對應的postion，在進行時間點還原時，可以通過這些信息確定二進制日誌的重放起始位置
innobackupex -p123123 /backup/
如果想要使用xtrabackup備份衆多數據庫中的某一個，那麼必須保證在創建這個數據庫時，已經開啓了innodb_file_per_table參數，否則將無法單獨備份數據庫服務器中的某一個數據庫。
包含了my.cnf中的一些設置信息，但是，並不是my.cnf中的所有信息都會包含在此文件中，此文件中只包含了備份時需要的信息
backup-my.cnf
記錄了備份開始時二進制日誌文件的位置
xtrabackup_binlog_info
記錄此次備份屬於那種類型的備份，是全量還是增量，備份時起始的LSN號碼，結束的LSN號碼等信息
xtrabackup_checkpoints
備份的概要信息
xtrabackup_info
備份過程中的日誌，在對數據進行prepare時需要通過日誌將數據還原成一致的可用的數據。
xtrabackup_logfile
通過全量備份進行數據庫恢復，將原來的備份拷貝至進行還原操作的主機上
scp -r /backup/2017-04-06_21-53-13/ 192.168.1.120:/testdir/
備份出的數據並不能直接使用，因爲備份出的數據是不一致的，需要將同時備份出的事務日誌應 用到備份中，才能得到一份完整、一致、可用的數據，xtrabackup稱這一步操作爲prepare
–apply-log選項，表示將目錄中的日誌應用到備份數據中
innobackupex --apply-log /testdir/2017-04-06_21-53-13/
如果備份的數據量巨大，那麼備份時長會變長，期間備份的事務日誌容量 有可能會很大。使用–use-memory選項，加速準備工作的完成，在不指定內存大小的情況下，準備工作默認會佔用100MB的內存， 如果服務器有一定的空閒內存，那麼可以讓xtrabackup使用指定大小的內存完成準備工作，以提升準備工作完成的速度
innobackupex --apply-log --use-memory=4G /testdir/2017-04-06_21-53-13/
把可用的備份拷貝回數據庫的數據目錄即可
innobackupex --datadir=/var/lib/mysql --copy-back /testdir/2017-04-06_21-53-13/
將準備好的可用數據，"拷貝回"要恢復的數據目錄中。–datadir選項指定的目錄就是數據目錄，指定的數據目錄爲rpm安裝的mysql的默認數據目錄，如果數 據庫的my.cnf配置文件中已經設置了datadir對應的目錄，那麼則可以省略–datadir選項，innobackupex在執行 copyback時會讀取數據庫的my.cnf中的配置，但是如果my.cnf中沒有配置datadir，那麼–datadir選項必須存在，而 且，datadir目錄必須爲空目錄，其中不能存在數據，否則在執行上述命令時會報錯，–copy-back選項對應的目錄就是準備好的可用數據的 目錄。爲了能夠正常的恢復數據，先確定數據庫服務已經停止了，而且對應的數據目錄中不存在數據，然後進行數據還原工作，刪除數據目錄中的文件與日誌。
還不能啓動mysql，因爲是使用root用戶拷貝的數據，所以數據目錄中的數據文件的屬主屬組仍然爲root，沒錯，需要將這些文件的屬主屬組設置爲mysql。
chown -R mysql: /var/lib/mysql/
2.2.4 xtrabackup全量備份與恢復的命令
執行全量備份
innobackupex --defaults-file=/etc/my.cnf --host=192.168.1.71 --user=root --password=123123 /backup
簡易的全量備份
innobackupex -p123123 /backup
如果在另一臺mysql服務器上恢復，則先確保已經安裝了同樣版本的mysql，並且安裝了xtrabackup。將全量備份拷貝至新的mysql服務器上
scp -r /backup/2017-04-06_21-53-13/ 192.168.1.120:/testdir/
對數據進行準備工作，合成可用的一致的數據，–use-memory選項不是必須的
innobackupex --apply-log --use-memory=4G /testdir/2017-04-06_21-53-13/
完成準備工作後，確定新的MySQL服務器上的mysql服務已經停止，確定對應的數據目錄中沒有任何文件，刪除數據目錄與對應日誌
systemctl stop mariadb
rm -rf /var/lib/mysql/*
將準備好的數據還原回對應的數據目錄中
innobackupex --datadir=/var/lib/mysql --copy-back /testdir/2017-04-06_21-53-13/
數據還原拷貝完成後，將對應數據目錄中的文件的屬主屬組設置爲mysql用戶
chown -R mysql: /var/lib/mysql/
啓動mysql服務實際還原時最好將對應的配置文件（例如my.cnf）也都還原了，所有數據還原後，再啓動mysql服務（未涉及時間點還原）。
systemctl start mariadb
2.2.5 xtrabackup增量備份及恢復
全量備份是差量與增量的基礎，因爲差量備份只能針對於上一次全量備份，增量備份則可以針對上一次任何一種備份，上一次備份可以是全量、差量、或者增 量，但是不管怎麼樣，總是要有一份全量備份作爲基礎的，不管是增量備份還是差量備份，都是對於innodb表來說的，對於myisam表，即使執行了所謂 的"增量"備份，其實也是全量備份。
全量備份，在/backup目錄下，可以看到備份時間爲名稱的備份文件夾
innobackupex -p123123 /backup
查看本次全量備份的xtrabackup_checkpoints文件，可以發現，此文件中記錄了此次備份的類型爲"全量備份"，備份page的LSN範圍爲0到61715333。
cat /backup/2017-04-08_13-36-11/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 61715333
last_lsn = 61715333
compact = 0
recover_binlog_info = 0
增量備份是針對上一次備份來說的，所以，在進行增量備份時，需要指定以哪個備份作爲上一次的備份
innobackupex -p123123 --incremental /backup --incremental-basedir=/backup/2017-04-08_13-36-11/
–incremental選項表示本次備份是一個增量備份（其實這次備份既可以算是增量，也可以算作差量），本次增量備份將 備份至/backup目錄下，本次增量備份是針對於/backup/2017-04-08_13-36-11/的增量，使用上述命令也可以實現差量備份，如果想要實現差量備份，只要將–incremental-basedir選項的值每次都設定爲全量 備份的路徑即可，其實這次備份也可以理解爲一次差量備份。
查看增量備份目錄中的xtrabackup_checkpoints文件內容，發現其中已經爲標註好了，本次備份是一個增量備份，並且，爲記錄了本次備份的起始LSN與結束LSN，本次備份的起始LSN與上次全量備份的結束LSN號碼相同。
cat /backup/2017-04-08_13-41-59/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 61715333
to_lsn = 61716055
last_lsn = 61716055
compact = 0
recover_binlog_info = 0
開始新的增量備份，這次的增量備份是基於上一次備份進行的，所以，要指定上一次的備份位置，只不過，上一次備份也是增量備份
innobackupex -p123123 --incremental /backup --incremental-basedir=/backup/2017-04-08_13-41-59
查看這一次增量備份的checkpoints文件，可以看到，這次備份起始的LSN號與上一次備份結束的LSN號相同
cat /backup/2017-04-08_14-01-16/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 61716055
to_lsn = 61716350
last_lsn = 61716350
compact = 0
recover_binlog_info = 0
再次查看備份目錄，發現已經存在了一個全量備份目錄與兩個增量備份目錄。
ls /backup
2017-04-08_13-36-11 2017-04-08_13-41-59 2017-04-08_14-01-16
使用上述3個備份將數據還原（此處不考慮時間點還原），爲了不影響現在的服務運行，將備份還原到一臺新的服務器上。
如果在另一臺mysql服務器上恢復，則先確保已經安裝了同樣版本的mysql，並且安裝了xtrabackup。
將所有備份拷貝至新的mysql服務器上
scp -r /backup/* 192.168.1.120:/testdir/
在恢復全量備份時，只需要對全量備份進行準備操作即可，但是此時，除了全量備份，還有增量備份， 由於有多個備份，所以準備工作要進行多次，首先，先對全量備份進行準備工作。
innobackupex --apply-log --redo-only --use-memory=1G /testdir/2017-04-08_13-36-11/
–redo-only選項表示在進行準備（應用日 志）工作時，只進行redo操作，因爲在備份開始時，有的事務日誌已經提交了，但是還沒有完全應用到數據文件中，有的事務日誌還沒有提交，這些沒有提交的 事務需要進行回滾操作，在進行"準備"工作時，如果添加了–redo-only選項，則只會重做已提交但是未應用的事務，而不會回滾未提交的事務，爲什 麼前文中的準備工作中，沒有添加–redo-only選項呢，那是因爲，前文中只還原了一個全量備份，全量備份之後沒有任何其他備份需要合併，而此刻則 不同，除了全量備份，後面還有對應的增量備份，那麼全量備份中未提交的事務有可能在後面的增量備份中已經提交了，所以，在準備"最後一份備份"之前的"備 份"時，都不用進行回滾操作，只在最後一次備份中進行回滾操作即可。
將第一次進行的增量備份合併到之前準備好的完全備份中
innobackupex --apply-log --redo-only --use-memory=1G /testdir/2017-04-08_13-36-11/ --incremental-dir=/testdir/2017-04-08_13-41-59
仍然使用了–redo-only選項，並且使用了–incremental-dir選項，此選項對應的目錄爲增量備份文件的目錄，對增量備份進行準備工作，並且把準備好的增量備份合併到對應的全量備份中。第一份增量備份已經整理完畢，並且已經將增量合併到了對應的全量備份中，查看全量備份中的 xtrabackup_checkpoints文件，會發現全量備份的備份類型已經變爲了"log-applied"，這個備份已經經歷過了日誌應用的過程（已經做過了準備 工作），而且，對應的最大的LSN號碼爲61716055，此LSN正是第一次增量的結束LSN，也就是說，已經將第一次增量與全量整合在了一起。
cat /testdir/2017-04-08_13-36-11/xtrabackup_checkpoints
backup_type = log-applied
from_lsn = 0
to_lsn = 61716055
last_lsn = 61716055
compact = 0
recover_binlog_info = 0
合併最後一份增量了
innobackupex --apply-log --use-memory=1G /testdir/2017-04-08_13-36-11/ --incremental-dir=/testdir/2017-04-08_14-01-16
因爲是最後一份備份數據，所以並不用添加–redo-only選項，事務日誌需要應用，該提交的提交，該回滾的回滾，-- incremental-dir對應的目錄爲最後一次增量備份的目錄，表示準備最後一次的增量備份，並且將準備好的增量備份合併到上次準備好的全量備份 中。查看對應的全量備份目錄中的xtrabackup_checkpoints文件，發現對應的LSN號碼已經變爲最後一次增量備份的結束LSN號碼了。
cat /testdir/2017-04-08_13-36-11/xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 61716350
last_lsn = 61716350
compact = 0
recover_binlog_info = 0
把所有增量備份都合併到了最初的第一份全量備份中，只要通過這一份全量備份即可恢復數據庫。確定新的MySQL服務器上的mysql服務已經停止，確定對應的數據目錄中沒有任何文件，那麼，刪除對應的數據文件與日誌。
systemctl stop mariadb
rm -rf /var/lib/mysql/*
完成上述工作後，將準備好的數據還原回對應的數據目錄中，沒錯，只將最後合併完成的那個全量備份還原即可，因爲之前的準備工作中，已經將所有增量數據都合併到這個全量中了。
innobackupex --datadir=/var/lib/mysql --copy-back /testdir/2017-04-08_13-36-11
數據還原拷貝完成後，將對應數據目錄中的文件的屬主屬組設置爲mysql用戶
chown -R mysql: /var/lib/mysql/
完成上述步驟後，啓動mysql服務，當然，實際還原時最好將對應的配置文件（例如my.cnf）也都還原了，所有數據還原後，再啓動mysql服務。
systemctl start mariadb
登錄數據庫，查看對應的數據，都已經被正常的還原了，沒有進行時間點還原。
2.3 xtrabackup支持的備份類型
並行備份
xtrabackup支持並行備份，就是備份時同時開啓多個線程，並行的進行備份操作，這樣可以加快備份完成的速度，但是會增大IO，默認情況下之開啓一個進程進行備份。使用–parallel選項指定並行備份的線程數量。備份數據量較大時使用–parallel選項可以加快備份完成的速度
innobackupex -p123123 --parallel=8 /backup
節流備份
xtrabackup支持節流備份，節流備份的意思就是節省IO操作的備份，當數據庫服務器上已經沒有過多的空閒IO時，可以使用節流備份。使用–throttle選項限制每秒鐘操作IO的次數。–throttle選項只適用於備份階段，不能用於prepare階段與copy-back階段。
innobackupex -p123123 --throttle=200 /backup
壓縮備份
xtrabackup支持壓縮功能，使用壓縮功能可以在備份時直接生成經過壓縮的備份。有兩種方法直接生成經過壓縮的備份。
方法一：使用–compress選項進行壓縮
方法二：使用流的方式進行備份，將備份的tar格式的流重定向到其他壓縮軟件進行壓縮
innobackupex -p123123 --compress /backup
使用–compress-threads=#選項可以指定壓縮線程的數量，加快壓縮的速度
innobackupex -p123123 --compress --compress-threads=8 /backup
同時使用–parallel選項與 --compress-threads選項
innobackupex -p123123 --parallel=8 --compress --compress-threads=8 /backup
備份經過壓縮以後，在還原備份數據之前，則需要先進行解壓操作。使用–compress選項壓縮備份文件時，使用的壓縮算法爲"quicklz"，“quicklz"也是一個壓縮庫，“quicklz"官網號稱自己是全世界最快的壓縮庫，http://www.quicklz.com/，qpress就是quicklz的壓縮軟件，如果想要解壓備份文件中以”.qp"結尾的文件，則需要安裝"qpress”。進入壓縮後的備份目錄，可以發現，除了xtrabackup_checkpoints文件以外，其他文件都被壓縮成了以".qp"結尾的壓縮文件。
wget http://www.quicklz.com/qpress-11-linux-x64.tar
mv qpress /usr/local/bin/
使用qpress的-d選項進行解壓操作
qpress -d test.qp ./
for bf in `find . -iname "*\.qp"`; do qpress -d $bf $(dirname $bf) && rm $bf; done
通過innobackupex的–decompress選項解壓，需要安裝qpress
innobackupex --decompress /backup/2013-08-01_11-24-04/
使用–decompress選項時，可以配合–parallel選項，加速解壓操作的進度
innobackupex --parallel=4 --decompress 2017-04-11_11-50-31/
流備份
xtrabackup支持流式備份，即將備份數據以數據流的方式輸出。使用–stream選項則可以實現流備份，xtrabackup支持兩種格式的流：tar格式的流與xbstream格式的流。
tar格式流備份
tar格式的流當做標準輸出輸出到屏幕上，雖然指定了/backup目錄，但是並不能在對應目錄下生成備份文件
innobackupex -p123123 --stream=tar /backup
tar格式的流進行重定向，使用如下命令進行tar格式的流備份，–stream=tar後面的路徑不可省略，省略後報錯
innobackupex -p123123 --stream=tar /backup > /backup/back.tar
在解壓tar格式的流備份時，需要使用tar命令的-i選項
tar -ixvf /backup/back.tar
在生成流備份文件時，進行壓縮，將tar格式的留備份進行gzip壓縮使用，一步就完成了備份歸檔壓縮
innobackupex -p123123 --stream=tar /backup | gzip > /backup/fullback.tar.gz
將數據直接備份到遠程主機，需要對當前主機ssh信任，不佔用本機的磁盤空間
innobackupex -p123123 --stream=tar /tmp | ssh [email protected] \ “cat - > /backup/bak.tar”
在流備份到遠程主機時對備份進行壓縮
innobackupex -p123123 --stream=tar /tmp | ssh [email protected] \ “gzip > /backup/dateFullBak.tar.gz”;
xbstream格式流備份
將xbstream格式的數據流重定向到了/backup/fullbak.xbstream文件中
innobackupex -p123123 --stream=xbstream ./ > /backup/fullbak.xbstream
在備份時直接進行壓縮
innobackupex -p123123 --stream=xbstream --compress ./ > /backup/fullbak.xbstream
使用xbstream命令釋放xbstream格式的流備份文件，在安裝xtrabackup時就已經安裝了xbstream命令，，-x選項表示釋放xbstream流備份文件到當前目錄
xbstream -x < bakup.xbstream
釋放xbstream流備份文件到指定的目錄，使用-C選項
xbstream -x -C /backup/zsythink/ < fullbak.xbstream
將xbstream流直接備份到遠程主機上，將流備份備份到遠程主機有一個前提條件，就是存儲備份的目標主機需要對當前主機ssh信任
innobackupex -p123123 --stream=xbstream --compress /tmp | ssh [email protected] “xbstream -x -C /backup/datafull”
————Blueicex 2020/3/29 16:37 [email protected]