1 概述
1.1 简介
Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。
PXB（Percona XtraBackup）是物理备份，是基于复制文件备份，备份时可以远程操作，基于mysql协议远程连接，需要备份的主机不用安装PXB，但是，执行恢复数据操作时mysql服务不能启动，所以恢复时只能本地恢复，而且在本地的服务器上要安装PXB
PXB在恢复增量数据时，先合并第一次增量到全量上，然后合并第二次增量。。。合并最后一次增量，最后一次增量被合并后，有问题的事务才会被回滚，所有增量都被合并到一起后，再复制到数据目录下，然后才启动mysql服务。mysql服务器启动后，最后一次增量之后的少量数据，同样要根据二进制日志文件进行恢复。
PXB实现单表导入和导出，innodb要实现必须要启用单表功能，因为如果不开启该功能，innodb中把frm和fbm复制到另一个mysql中，另一个mysql是无法加载这个表的，因为新的服务器不能识别复制过来的表空间，服务器内部记录的lsn（日志序列号）不一样，另一台机器上是不能识别的。myISAM没有这个问题，所有的表复制到其他的mysql可以被识别。
执行热备时，备份启动时，可能有些事务该执行一半，即正在执行中的事务，所以为了确保已经提交的事务是完整的，PXB也会一起备份事务日志，这样才能知道对应的事务的状态，还原的时候，才能确保mysql可以被启动。
启动前，会根据事务日志，将该提交的提交（执行完的事务尚未提交，还保存在事务日志中），将该回滚的回滚，相当于是数据库的崩溃后修复操作，这样才能把数据库服务正常启动。
备份时要备份事务日志，这是一定要执行的。
如果是全量+增量的备份，如果全量备份中，有些执行中的事务此时不能被回滚，因为可能是在增量备份中已经被commit了，所以恢复的时候，必须是最后一次增量被恢复后，有问题的事务才会被回滚
1.2 PXB特点
(1)备份过程快速、可靠；
(2)备份过程不会打断正在执行的事务；
(3)能够基于压缩等功能节约磁盘空间和流量；
(4)自动实现备份检验；
(5)还原速度快；
1.3 安装
其最新版的软件可从 http://www.percona.com/software/percona-xtrabackup/ 获得。本文基于RHEL5.8的系统，因此，直接下载相应版本的rpm包安装即可，这里不再演示其过程。
安装PXB
版本是percona-xtrabackup-24-2.4.7-2.el7.x86_64.rpm
[root@CentOS7A yum.repos.d]#yum -y install /root/percona-xtrabackup-24-2.4.7-2.el7.x86_64.rpm
其中，安装的工具中/usr/bin/innobackupex工具使用perl语言对xtrabackup做了二次封装，支持客户端远程连接的方式备份
2 备份的实现
2.1 完全备份
#注意，如果没有指定数据库，则表示备份所有的库，会在目录 /path/to/BACKUP-DIR/下创建以当前日期为名称的目录，把备份出的所有文件放到该日期目录下，备份和恢复要注意属主和属组的问题，可能备份出的文件属组和属主都会root权限，注意还原属组和属主，没有指定备份方式，则是全量备份
语法如下
# innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
如果要使用一个最小权限的用户进行备份，则可基于如下命令创建此类用户：
mysql> CREATE USER ’bkpuser’@’localhost’ IDENTIFIED BY ’s3cret’;
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM ’bkpuser’;
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ’bkpuser’@’localhost’;
mysql> FLUSH PRIVILEGES;
使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命名的目录中。
在备份的同时，innobackupex还会在备份目录中创建如下文件：
(1)xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；
每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。
(2)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。
(3)xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。
(4)xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；
(5)backup-my.cnf —— 备份命令用到的配置选项信息；
在使用innobackupex进行备份时，还可以使用--no-timestamp选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据。
2.2 准备(prepare)一个完全备份
一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
innobakupex命令的--apply-log选项可用于实现上述功能。如下面的命令：
# innobackupex --apply-log /path/to/BACKUP-DIR
如果执行正确，其最后输出的几行信息通常如下：
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120407 9:01:36 InnoDB: Starting shutdown...
120407 9:01:40 InnoDB: Shutdown completed; log sequence number 92036620
120407 09:01:40 innobackupex: completed OK!
在实现“准备”的过程中，innobackupex通常还可以使用--use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。
2.3、从一个完全备份中恢复数据
注意：恢复不用启动MySQL
innobackupex命令的--copy-back选项用于执行恢复操作，其通过复制所有数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。innobackupex通过backup-my.cnf来获取DATADIR目录的相关信息。
# innobackupex --copy-back /path/to/BACKUP-DIR
如果执行正确，其输出信息的最后几行通常如下：
innobackupex: Starting to copy InnoDB log files
innobackupex: in '/backup/2012-04-07_08-17-03'
innobackupex: back to original InnoDB log directory '/mydata/data'
innobackupex: Finished copying back files.
120407 09:36:10 innobackupex: completed OK!
请确保如上信息的最行一行出现“innobackupex: completed OK!”。
当数据恢复至DATADIR目录以后，还需要确保所有数据文件的属主和属组均为正确的用户，如mysql，否则，在启动mysqld之前还需要事先修改数据文件的属主和属组。如：
# chown -R mysql:mysql /mydata/data/
2.4 使用innobackupex进行增量备份
每个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础，即innobackupex通过备份上次完全备份之后发生改变的页面来实现。
要实现第一次增量备份，可以使用下面的命令进行：
# innobackupex --incremental /backup --incremental-basedir=BASEDIR
其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外，在执行过增量备份之后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。
需要注意的是，增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。
“准备”(prepare)增量备份与整理完全备份有着一些不同，尤其要注意的是：
(1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。
(2)基于所有的备份将未提交的事务进行“回滚”。
于是，操作就变成了：
# innobackupex --apply-log --redo-only BASE-DIR
接着执行：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
而后是第二个增量：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
其中BASE-DIR指的是完全备份所在的目录，而INCREMENTAL-DIR-1指的是第一次增量备份的目录，INCREMENTAL-DIR-2指的是第二次增量备份的目录，其它依次类推，即如果有多次增量备份，每一次都要执行如上操作；
最后一个增量命令完成后，要在全量备份上做“回滚”操作。
# innobackupex --apply-log BASE-DIR
2.5 Xtrabackup的“流”及“备份压缩”功能
Xtrabackup对备份的数据文件支持“流”功能，即可以将备份的数据通过STDOUT传输给tar程序进行归档，而不是默认的直接保存至某备份目录中。要使用此功能，仅需要使用--stream选项即可。如：
# innobackupex --stream=tar /backup | gzip > /backup/`date +%F_%H-%M-%S`.tar.gz
甚至也可以使用类似如下命令将数据备份至其它服务器：
# innobackupex --stream=tar /backup | ssh [email protected] "cat - > /backups/`date +%F_%H-%M-%S`.tar"
此外，在执行本地备份时，还可以使用--parallel选项对多个文件进行并行复制。此选项用于指定在复制时启动的线程数目。当然，在实际进行备份时要利用此功能的便利性，也需要启用innodb_file_per_table选项或共享的表空间通过innodb_data_file_path选项存储在多个ibdata文件中。对某一数据库的多个文件的复制无法利用到此功能。其简单使用方法如下：
# innobackupex --parallel /path/to/backup
同时，innobackupex备份的数据文件也可以存储至远程主机，这可以使用--remote-host选项来实现：
# innobackupex [email protected] /path/IN/REMOTE/HOST/to/backup
2.6 导入或导出单张表
默认情况下，InnoDB表不能通过直接复制表文件的方式在mysql服务器之间进行移植，即便使用了innodb_file_per_table选项。而使用Xtrabackup工具可以实现此种功能，不过，此时需要“导出”表的mysql服务器启用了innodb_file_per_table选项（严格来说，是要“导出”的表在其创建之前，mysql服务器就启用了innodb_file_per_table选项），并且“导入”表的服务器同时启用了innodb_file_per_table和innodb_expand_import选项。
(1)“导出”表
导出表是在备份的prepare阶段进行的，因此，一旦完全备份完成，就可以在prepare过程中通过--export选项将某表导出了：
# innobackupex --apply-log --export /path/to/backup
此命令会为每个innodb表的表空间创建一个以.exp结尾的文件，这些以.exp结尾的文件则可以用于导入至其它服务器。
(2)“导入”表
要在mysql服务器上导入来自于其它服务器的某innodb表，需要先在当前服务器上创建一个跟原表表结构一致的表，而后才能实现将表导入：
mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;
然后将此表的表空间删除：
mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
接下来，将来自于“导出”表的服务器的mytable表的mytable.ibd和mytable.exp文件复制到当前服务器的数据目录，然后使用如下命令将其“导入”：
mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
2.7 使用Xtrabackup对数据库进行部分备份
Xtrabackup也可以实现部分备份，即只备份某个或某些指定的数据库或某数据库中的某个或某些表。但要使用此功能，必须启用innodb_file_per_table选项，即每张表保存为一个独立的文件。同时，其也不支持--stream选项，即不支持将数据通过管道传输给其它程序进行处理。
此外，还原部分备份跟还原全部数据的备份也有所不同，即你不能通过简单地将prepared的部分备份使用--copy-back选项直接复制回数据目录，而是要通过导入表的方向来实现还原。当然，有些情况下，部分备份也可以直接通过--copy-back进行还原，但这种方式还原而来的数据多数会产生数据不一致的问题，因此，无论如何不推荐使用这种方式。
(1)创建部分备份
创建部分备份的方式有三种：正则表达式(--include), 枚举表文件(--tables-file)和列出要备份的数据库(--databases)。
(a)使用--include
使用--include时，要求为其指定要备份的表的完整名称，即形如databasename.tablename，如：
# innobackupex --include='^mageedu[.]tb1' /path/to/backup
(b)使用--tables-file
此选项的参数需要是一个文件名，此文件中每行包含一个要备份的表的完整名称；如：
# echo -e 'mageedu.tb1\nmageedu.tb2' > /tmp/tables.txt
# innobackupex --tables-file=/tmp/tables.txt /path/to/backup
(c)使用--databases
此选项接受的参数为数据名，如果要指定多个数据库，彼此间需要以空格隔开；同时，在指定某数据库时，也可以只指定其中的某张表。此外，此选项也可以接受一个文件为参数，文件中每一行为一个要备份的对象。如：
# innobackupex --databases="mageedu testdb" /path/to/backup
(2)整理(preparing)部分备份
prepare部分备份的过程类似于导出表的过程，要使用--export选项进行：
# innobackupex --apply-log --export /pat/to/partial/backup
此命令执行过程中，innobackupex会调用xtrabackup命令从数据字典中移除缺失的表，因此，会显示出许多关于“表不存在”类的警告信息。同时，也会显示出为备份文件中存在的表创建.exp文件的相关信息。
(3)还原部分备份
还原部分备份的过程跟导入表的过程相同。当然，也可以通过直接复制prepared状态的备份直接至数据目录中实现还原，不要此时要求数据目录处于一致状态。
3 例子
3.1 使用xtrabackup进行本地全量的备份和恢复
完全+binlog
备份：innobackupex --user --password= --host= /PATH/TO/BACKUP_DIR
准备：innobackupex --apply-log /PATH/TO/BACKUP_DIR
恢复：innobackupex --copy-back
注意：--copy-back需要在mysqld主机本地进行，mysqld服务不能启动；innodb_log_file_size可能要重新设定；
实例如下
数据备份：
创建备份的目录
[root@CentOS7A yum.repos.d]#mkdir /mydata/backups
执行备份
[root@CentOS7A yum.repos.d]#innobackupex --user=root --password=Pass1234 --host=localhost /mydata/backups/
最后看到如下信息，表示备份完成
xtrabackup: Transaction log of lsn (65107278) to (65107278) was copied.
180115 17:27:11 completed OK!
完成后，生成以时间命名的目录如下，该目录下有对应数据库的文件
/mydata/backups/2018-01-15_17-26-59
/mydata/backups/2018-01-15_17-26-59目录下查看复制的内容如下，
[root@CentOS7A 2018-01-15_17-26-59]#ls /mydata/backups/2018-01-15_17-26-59
backup-my.cnf mysql sunny xtrabackup_checkpoints xtrabackup_logfile
ibdata1 performance_schema xtrabackup_binlog_info xtrabackup_info zbxproxydb
除了数据库中原来库，其他的文件介绍如下
backup-my.cnf:myslq服务器的配置信息,这些配置信息对将来重新启动服务至关重要。
xtrabackup-binlog_info:记录二进制文件的信息，指备份的那个时间段处于哪个二进制文件的哪个位置
xtrabackup-checkpoints:检查点，记录备份自己的属性,如 lsn，其中，compact是指有没有打包，backup_type指备份的类型，recover_binlog_info有没有需要通过binlog恢复的备份信息
xtrabackup-info：记录备份工具自身的信息，如备份时使用什么工具，使用什么选项连接服务器等信息，服务器版本，备份时间，恢复的时候，需要依赖这些信息进行恢复。PXB恢复数据时需要依赖这些信息来判断如何恢复
xtrabackup-logfile：PXB执行时的log信息，这是二进制信息,不能用cat查看。
一般还会有事务日志，如果当前是干净的，如没有未提交的事务，可能就不会复制事务日志，但是一般生产环境是存在为提交的事务，所以，一般会有事务日志
注意，为了数据安全起见，不要把备份后的数据还是保存在本地mysql的服务器上，否则，服务器崩溃，可能导致备份的数据也丢失，这样就起不到数据备份的作用。或者，备份后可以将生成的备份文件完整打包，放到另一个服务器上。
数据恢复：
将以上的备份信息恢复备份到另一台机器75上，另一台机器也要装PXB，因为恢复操作需要借助PXB
将71备份的数据拷贝到75上
[root@CentOS7A ~]#scp -r /mydata/backups/2018-01-15_17-26-59/ 192.168.1.75:/root
先停止75服务器上的mysql服务
[root@CentOS7E source]#systemctl stop mariadb.service
75上安装PXB
[root@CentOS7E ~]#yum -y install /root/percona-xtrabackup-24-2.4.7-2.el7.x86_64.rpm
恢复操作，准备一台干净的mysql数据库，即/var/lib/mysql目录下没有内容，如果有内容，需要清空，清空前先确认一下数据是否还有用
使用选项--apply-log:该选项将应用事务日志到数据文件，要回滚的事务回滚，提交的提交，进行数据的同步，还没开始恢复数据，是恢复前的准备工作
进入75上备份数据的目录下
[root@CentOS7E ~]#cd /root/2018-01-15_17-26-59/
[root@CentOS7E 2018-01-15_17-26-59]#innobackupex --apply-log ./
看到如下信息为完成
InnoDB: Shutdown completed; log sequence number 65107505
180115 17:58:44 completed OK!
此时，恢复前的准备工作完成
执行以下命令，自动加载配置文件，获取相关的信息，如数据目录的路径，进行数据恢复时会将数据恢复到数据目录下
[root@CentOS7E 2018-01-15_17-26-59]#innobackupex --copy-back ./
看到如下信息，则数据恢复成功
180115 19:52:17 completed OK!
更改文件的属主和属组
[root@CentOS7E mysql]#chown -R mysql.mysql /var/lib/mysql/*
重启服务
[root@CentOS7E mysql]#systemctl restart mariadb
到这里全量备份恢复完成，注意，完成后，在75这台再做一次全量备份，以备后续可能75故障，需要在另一台mysql服务器上进行全量备份，原来71的全量备份文件已经不能用。
注意，备份的操作，可以用脚本操作，写成计划任务，定时完成。但是，恢复的操作，建议一定要手工执行，因为有可能恢复过程出现问题，有可能损坏备份，就出现麻烦，所以，恢复的操作，建议平常进行演练，保证出现问题，可以及时进行恢复
3.2 全量+增量备份，同时用二进制文件实现时间点还原
完全+增量+binlog
备份：完全+增量+增量+...
完全+差异
准备：
innobackupex --apply-log --redo-only BASEDIR
innobackupex --apply-log --redo-only BASEDIR --incremental-dir=INCREMENTAL-DIR
恢复：
innobackupex --copy-back BASEDIR
实例如下
完成全量备份
[root@CentOS7A mysql]#innobackupex --user=root --host=localhost --password=Pass1234 /mydata/backups
第一次增量备份如下，选项--incremental指明位置，--incremental-basedir指明基于哪一次的基础增量
[root@CentOS7A mysql]#innobackupex --user=root --host=localhost --password=Pass1234 --incremental /mydata/backups --incremental-basedir=/mydata/backups/2018-01-15_20-10-02
会生成一个新的文件，此时目录名称是 2018-01-15_20-23-13
检查如下，查看 2018-01-15_20-23-13下的xtrabackup_checkpoints文件
[root@CentOS7A 2018-01-15_20-23-13]#cat /mydata/backups/2018-01-15_20-23-13/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 65109252
to_lsn = 65110280
last_lsn = 65110280
compact = 0
第二次增量备份，如果此时的增量是基于全量来做，则为差异备份，如果此时是基于第一次的增量，即 --incremental-basedir=/mydata/backups/2018-01-15_20-23-13，则为增量备份。
这里演示的是基于第一次的增量再一次进行增量
[root@CentOS7A backups]#innobackupex --user=root --host=localhost --password=Pass1234 --incremental /mydata/backups --incremental-basedir=/mydata/backups/2018-01-15_20-23-13
则在/mydata/backups下生成新的目录2018-01-15_21-34-33
检查二进制文件的位置信息
[root@CentOS7A 2018-01-15_21-34-33]#cat /mydata/backups/2018-01-15_21-34-33/xtrabackup_binlog_info
master-log.000005 2714
此时，不做备份，但是更新一下数据库，在数据库中的二进制文件会继续记录信息
MariaDB [sunny]> update students set major="maths" where age=90;
然后检查一下二进制日志文件
[root@CentOS7A 2018-01-15_21-34-33]#mysqlbinlog -j 2714 /mydata/log/master-log.000005
有一条记录为
update students set major="maths" where age=90
但是不做备份操作，假设此时数据库崩溃了，目前备份的数据没有最后一个更新age=90的数据，因此，恢复数据需要拿二进制日志文件进行恢复，保存该二进制文件记录，跳过之前有备份的信息，从master-log.000005文件的2714字节开始记录
[root@CentOS7A 2018-01-15_21-34-33]#mysqlbinlog -j 2714 /mydata/log/master-log.000005 >/tmp/mybinlog.sql
恢复数据
首先，准备一台感觉的mysql服务器，没有做过任何初始化配置，目录/var/lib/mysql下是空的。
这里假设ip是73服务器
停止mysql服务
[root@node73 mysql]#systemctl stop mariadb
安装PXB
yum -y install /root/percona-xtrabackup-24-2.4.7-2.el7.x86_64.rpm
进行数据恢复前，先将数据合并到完全备份，进行整合，前几次要添加选项--redo-only，最后合并完成后，基于所有的备份将未提交的事务进行“回滚”，注意，合并顺序很关键，增量要使用绝对路径，操作如下
进入全量备份的目录下，执行如下操作
[root@CentOS7A 2018-01-15_20-10-02]#innobackupex --apply-log --redo-only ./
接下来，还是在全量的目录下，开始合并第一个增量，指明增量目录，注意，增量要使用绝对路径
[root@CentOS7A 2018-01-15_20-10-02]#innobackupex --apply-log --redo-only ./ --incremental-dir=/mydata/backups/2018-01-15_20-23-13
第一个增量合并完成后，合并第二个增量
[root@CentOS7A 2018-01-15_20-10-02]#innobackupex --apply-log --redo-only ./ --incremental-dir=/mydata/backups/2018-01-15_21-34-33
第二个增量合并完成后，把没完成的事务回滚，即去掉--redo-only选项
[root@CentOS7A 2018-01-15_20-10-02]#innobackupex --apply-log ./
此时备份是一个完整的备份，拥有所有的增量
检查
在全量的目录下检查 xtrabackup_checkpoints文件的last_lsn已经是最后一个增量的数值，命令如下
[root@CentOS7A 2018-01-15_20-10-02]#cat xtrabackup_checkpoints
将71 上的合并后的全量备份的数据2018-01-15_20-10-02拷贝到73上，注意，这里合并后的全量备份数据下次恢复已经不能用了，因为已经做了合并和回滚，只能用于本次的数据恢复，本次数据恢复后，要对新的mysql服务器重新做一次全量备份，重新启动一个备份序列，以备下次恢复使用
[root@CentOS7A 2018-01-15_20-10-02]#scp -r /mydata/backups/2018-01-15_20-10-02 192.168.1.73:/root
数据拷贝完成后，到73这台mysql服务器上
进入拷贝过来的全量备份2018-01-15_20-10-02的目录下
[root@node73 ~]#cd /root/2018-01-15_20-10-02
[root@node73 2018-01-15_20-10-02]#innobackupex --copy-back ./
完成后，可以查看到数据已经被拷贝到/var/lib/mysql/下，更改/var/lib/mysql/目录下的所有组和所有主
[root@node73 mysql]#chown -R mysql.mysql /var/lib/mysql/*
启动服务
[root@node73 mysql]#systemctl start mariadb.service
此时，服务正常启动后，还需要做时间点数据还原，即将二进制日志文件进行重放，还原数据
此时检查一下数据库，进入数据库后
MariaDB [sunny]> select * from students where age=90;
age=90的major还没有被更新为maths
和保存下来的二进制文件/tmp/mybinlog.sql
scp /tmp/mybinlog.sql 192.168.1.73:/root
注意，这里将/root下的mybinlog.sql移动到/tmp下，这样所有的用户都能读取该目录下的文件，接下来直接采用在73mysql服务里直接用source来读取/tmp下的mybinlog.sql文件
恢复二进制日志前先临时关闭本机73的mysql二进制日志记录功能
MariaDB [sunny]> set @@session.sql_log_bin=OFF;
开始恢复二进制文件，三个方法
MariaDB [sunny]> source /tmp/mybinlog.sql
或者
MariaDB [sunny]> \. /tmp/mybinlog.sql
或者在shell里直接导入
[root@node73 ~]#mysql -uroot -pPass123456
完成后，再次开启二进制日志的记录功能
MariaDB [sunny]> set @@session.sql_log_bin=ON;
此时，备份完成，但是，先做一次全量备份，然后再将服务器上线
[root@node73 ~]#mkdir -p /mydata/backup73
[root@node73 ~]#innobackupex --user=root --host=localhost --password=Pass123456 /mydata/backup73
到此，备份完成，可以上线新恢复数据的mysql服务器