新版Xtrabackup --compress --compress-threads=4 --stream=xbstream --parallel=4流式备份及decompres和备份恢复到节点的说

采用流式备份好处就不多说了 官方推荐 这里就是说下备份完成之后要怎么回复

解压备份文件

xtrabackup --decompress --remove-original --parallel=4 --target-dir=/home/backup/20190701160001/

注意这里需要安装官方解压依赖的qpress ，或者pkgs.org可以自行下载并解压安装：

[root@localhost home]#tar xvf qpress-11-linux-x64.tar
[root@localhost home]#cp qpress /usr/bin

这里说明下参数

 --decompress  解压参数 这就不多说了
--remove-original 这个参数的意义就是解压完成后并删除压缩文件
--parallel 多线程解压 加速

准备备份文件

解压完的文件是不能直接用来恢复的 需要进行prepare

xtrabackup --prepare  --apply-log  --target-dir=/home/xbackdata/mysql

这里说法有点多XtraBackup备份恢复模拟实践，percona-xtrabackup使用如果是完整备份没有增备就不需要加–apply-log-only 如果是有增备数据，必须在除最后一次增备的prepare之外都要加–apply-log-only（innobackupex 对应的是 --redo-only），这个参数的作用咱们看下官方的解释：

The xtrabackup --prepare step for incremental backups is not the same as for full backups. In full backups,
two types of operations are performed to make the database consistent: committed transactions are replayed from the
log file against the data files, and uncommitted transactions are rolled back. You must skip the rollback of uncommitted
transactions when preparing an incremental backup, because transactions that were uncommitted at the time of your
backup may be in progress, and it’s likely that they will be committed in the next incremental backup. You should use
the xtrabackup --apply-log-only option to prevent the rollback phase.

Warning: If you do not use the xtrabackup --apply-log-only option to prevent the rollback phase,
then your incremental backups will be useless. After transactions have been rolled back, further incremental
backups cannot be applied.

--redo-only
This option should be used when preparing the base full backup and when merging all incrementals except
the last one. It is passed directly to xtrabackup’s xtrabackup --apply-log-only option. This forces
xtrabackup to skip the “rollback” phase and do a “redo” only. This is necessary if the backup will have
incremental changes applied to it later. See the xtrabackup documentation for details.

这个参数就是控制备份恢复过程中未提交的事务是否进行回滚 比如prepare第一个备份 将为conmmit的事务回滚了 数据就丢失了，进行第二个备份prepare时 又对上一回滚的数据提交了 但是实际已经回滚 最终就导致数据丢失无法继续恢复

备份原有mysql文件目录

这里最好是备份下 万一恢复失败了 还可以回滚，也可以忽略

将prepare之后的文件拷贝到mysql数据目

xtrabackup --copy-back --target-dir=/home/xbackdata/mysql

授权

这一步容易忽略 不是啥多大问题 但是通过日志在分析出来浪费时间

chown -R mysql:mysql /home/mysqldata/mysql/

启动mysql

service mysqld start

从binlog中继续恢复数据到出问题的时间点（mysqlbinlog将binlog转成sql）

参考：mysql通过mysqldump和mysqlbinlog恢复数据，binlog恢复数据失败解决方案xtrabackup中记录了binlog的文件起始位置，找打备份文件所在目录：

root@localhost 20190701160001]# cat xtrabackup_binlog_info
mysql-bin.000007	191	416cf17c-97ba-11e9-803f-005056be27d7:1-6

我们看到start-position是191 GTID是 416cf17c-97ba-11e9-803f-005056be27d7:1-6
下一步就是找到binlog文件并进行解析：

mysqlbinlog --no-defaults -vv --skip-gtids --start-position=191  -d back mysql-bin.000007>4.sql    # -d back是指定数据库名称解析

解析完成之后就可以打开找到出问题的sql所在的前一个sql的position 比如是345
然后进行指定position区间恢复

mysqlbinlog --no-defaults -vv --skip-gtids --start-position=191 --stop-position=345 -d back mysql-bin.000007>4.sql 

这样就得到了最终从备份之后到出问题之前的sql

导入从binlog恢复出来的sql文件

mysql -uroot -p <test_2016-08-02.sql