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]