此次演示使用xtrabackup来实现mysql的完全备份和完全备份+增量备份,以及备份后数据的恢复

说明:mysql数据存放路径为/mydata/data  备份数据路径为/backup

一、安装

 1、简介

Xtrabackup是由percona提供的mysql数据库备份工具,据官方介绍,这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。特点:

(1)备份过程快速、可靠;

(2)备份过程不会打断正在执行的事务;

(3)能够基于压缩等功能节约磁盘空间和流量;

(4)自动实现备份检验;

(5)还原速度快;

Xtrabackup包含两个主要的工具,即xtrabackup和innobackupex,二者区别如下:

(1)xtrabackup只能备份innodb和xtradb两种引擎的表,而不能备份myisam引擎的表;

(2)innobackupex是一个封装了xtrabackup的Perl脚本,支持同时备份innodb和myisam,但在对myisam备份时需要加一个全局的读锁。还有就是myisam不支持增量备份。

2、安装

其最新版的软件可从 http://www.percona.com/software/percona-xtrabackup/ 获得。本文基于RHEL5.8的系统,因此,直接下载相应版本的rpm包安装即可。

#rpm -ivh percona-xtrabackup-2.0.0-417.rhel5.i386.rpm

一个在centos 6.x 系统安装的例子:

#rpm -ivh percona-xtrabackup-24-2.4.7-1.el6.x86_64.rpm 
warning: percona-xtrabackup-24-2.4.7-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
error: Failed dependencies:
        libaio.so.1()(64bit) is needed by percona-xtrabackup-24-2.4.7-1.el6.x86_64
        libaio.so.1(LIBAIO_0.1)(64bit) is needed by percona-xtrabackup-24-2.4.7-1.el6.x86_64
        libaio.so.1(LIBAIO_0.4)(64bit) is needed by percona-xtrabackup-24-2.4.7-1.el6.x86_64
        libev.so.4()(64bit) is needed by percona-xtrabackup-24-2.4.7-1.el6.x86_64
        libnuma.so.1()(64bit) is needed by percona-xtrabackup-24-2.4.7-1.el6.x86_64
        perl(DBD::mysql) is needed by percona-xtrabackup-24-2.4.7-1.el6.x86_64        
根据提示可以得知,需要安装依赖包
#yum install libaio libev numactl perl-DBD-MySQL perl -y
再次安装
# rpm -ivh percona-xtrabackup-24-2.4.7-1.el6.x86_64.rpm 
warning: percona-xtrabackup-24-2.4.7-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
Preparing...                ########################################### [100%]
   1:percona-xtrabackup-24  ########################################### [100%]

二、备份命令介绍

 1、完全备份参数介绍

#innobackupex --user=DBUSER --password=DBUSERPASS  /path/to/BACKUP-DIR/
DBUSER     为执行备份任务的用户,此用户必须要有执行备份的权限,此次实验使用root用户
DBUSERPASS   执行备份任务用户的密码,本系统root用户密码为redhat
如果要使用一个最小权限的用户进行备份,则可基于如下命令创建此类用户:
mysql> CREATE USER ’bkpuser’@’localhost’ IDENTIFIED BY '123456';
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   #备份命令用到的配置选项信息;
(6)xtrabackup_logfile  #存放innodb的logfie
在使用innobackupex进行备份时,还可以使用--no-timestamp选项来阻止命令自动创建一个以时间命名的
目录;如此一来,innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据。

2、准备(prepare)一个完全备份

一般情况下,在备份完成后,数据尚且不能用于恢复操作,因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此,此时数据文件仍处于不一致状态.“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件,使得数据文件处于一致性状态。

 innobackupex命令的--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的过程,以提高其完成速度。

3、从一个完全备份中恢复数据

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/

三、具体备份恢复实现方式

演示一:完全备份以及数据恢复

(1).完全备份: 

注:这里是理想状态,是隔断外部所有进入mysql的连接请求,不会有任何DML操作数据写入!

#innobackupex --user=root --password=redhat /backup   #如果备份成功完成,会显示如下图:

注:会在备份后,提示你mysql binlog 名称以及位置。一个最近20170516,在测试环境备份的例子

#innobackupex --user=root --password=123456  --socket=/opt/app/mysql5/var/mysql.sock  /backup/
170516 23:43:42 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

170516 23:43:42  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/opt/app/mysql5/var/mysql.sock' as 'root'  (using password: YES).
170516 23:43:42  version_check Connected to MySQL server
170516 23:43:42  version_check Executing a version check against the server...
170516 23:43:42  version_check Done.
170516 23:43:42 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: /opt/app/mysql5/var/mysql.sock
Using server version 5.6.34-log
innobackupex version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /opt/app/mysql5/var/
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = /opt/app/mysql5/varinnodb
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = /opt/app/mysql5/varinnodb
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 536870912
InnoDB: Number of pools: 1
170516 23:43:42 >> log scanned up to (3040636)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 4 for mysql/slave_master_info, old maximum was 0
170516 23:43:43 [01] Copying /opt/app/mysql5/varinnodb/ibdata1 to /backup/2017-05-16_23-43-42/ibdata1
170516 23:43:43 >> log scanned up to (3040636)
170516 23:43:44 >> log scanned up to (3040636)
……………
……………
170516 23:43:52 [01] Copying ./performance_schema/events_stages_summary_by_thread_by_event_name.frm to /backup/2017-05-16_23-43-42/performance_schema/events_stages_summary_by_thread_by_event_name.frm
170516 23:43:52 [01]        ...done
170516 23:43:52 Finished backing up non-InnoDB tables and files
170516 23:43:52 [00] Writing xtrabackup_binlog_info
170516 23:43:52 [00]        ...done
170516 23:43:52 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '3040636'
xtrabackup: Stopping log copying thread.
.170516 23:43:52 >> log scanned up to (3040636)

170516 23:43:52 Executing UNLOCK TABLES
170516 23:43:52 All tables unlocked
170516 23:43:52 Backup created in directory '/backup/2017-05-16_23-43-42/'
MySQL binlog position: filename 'bin-log.000004', position '1443112'
170516 23:43:52 [00] Writing backup-my.cnf
170516 23:43:52 [00]        ...done
170516 23:43:52 [00] Writing xtrabackup_info
170516 23:43:52 [00]        ...done
xtrabackup: Transaction log of lsn (3040636) to (3040636) was copied.
170516 23:43:52 completed OK!
查看备份之后文件夹下面的内容
#ll /backup/2017-05-16_23-43-42/
total 75808
-rw-r----- 1 root root      419 May 16 23:43 backup-my.cnf
-rw-r----- 1 root root 77594624 May 16 23:43 ibdata1
drwxr-x--- 2 root root     4096 May 16 23:43 jiaowu
drwxr-x--- 2 root root     4096 May 16 23:43 mysql
drwxr-x--- 2 root root     4096 May 16 23:43 performance_schema
-rw-r----- 1 root root       23 May 16 23:43 xtrabackup_binlog_info
-rw-r----- 1 root root      113 May 16 23:43 xtrabackup_checkpoints
-rw-r----- 1 root root      506 May 16 23:43 xtrabackup_info
-rw-r----- 1 root root     2560 May 16 23:43 xtrabackup_logfile

(2)"准备"一个完全备份:

#innobackupex --apply-log /backup/2012-03-18_02-52-15/

准备成功后,会显示如下图所示信息:

然后模拟服务器出现故障了:

service mysqld stop         --首先停掉mysql服务器
#rm  -rf /mydata/data/*     --将mysql的数据存放目录下的文件全部删除,一定是数据存放目录!!!

(3).从完全备份中恢复数据:

#innobackupex --copy-back /backup/2012-03-18_02-52-15/

如果恢复能正常执行,将会显示如下图所示信息:

补充:如果在恢复的时候报错如下,则按照下面方式操作:

如果恢复数据的时候出现:
xtrabackup Error: datadir must be specified.
原因是xtrabackup不那么智能找到datadir,此时需要使用在my.cnf中指定datadir的目录
#innobackupex --defaults-file=/path/to/my.cnf --copy-back  /back/2012-x-x-x-

然后修改/mydata/data的属主和属组,并重启mysql服务:

#chown -R mysql.mysql /mydata/data

出现如下图所示的信息,表示数据恢复成功实现:

连接上mysql数据库,查看其中的表信息,能正常显示,说明数据恢复完成:

另外一个例子:如果mysql是自定义编译安装的,那么使用innobackupex进行备份与恢复,需要指定mysql的配置文件

备份命令:
#innobackupex --defaults-file=/opt/app/mysql/etc/my.cnf -uxxx -pxxxx --slave-info --parallel=8 --no-timestamp  /root/backup/
准备一个备份,后台运行
#nohup innobackupex --apply-log /root/backup/2018-06-22/ &
停止mysql 服务
#/opt/app/mysql/support-files/mysql.server stop
删除datadir 目录里面的文件
#rm -rf /opt/app/mysql/var/*
#rm -rf /opt/app/mysql/varinnodb/*
开始恢复数据,数据量比较大,放在后台运行
#nohup innobackupex --defaults-file=/opt/app/mysql/etc/my.cnf --copy-back /root/backup/2018-06-22/ &
等上面的命令执行结束,就重新启动mysql
先修改权限
#chown mysql.mysql /opt/app/mysql/var/ -R
#chown mysql.mysql /opt/app/mysql/varinnodb/ -R
启动
#/opt/app/mysql/support-files/mysql.server start

演示二:进行增量备份

每个InnoDB的页面都会包含一个LSN信息,每当相关的数据发生改变,相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础,即innobackupex通过备份上次完全备份之后发生改变的页面来实现。

要实现第一次增量备份,可以使用下面的命令进行:

# innobackupex --user=root --password=123456 --incremental /backup --incremental-basedir=BASEDIR 
其中:BASEDIR指的是完全备份所在的目录(就是第一次完全备份后在/backup目录中生成的那个以时间命名的目录
)此命令执行结束后,innobackupex命令会在/backup目录中创建一个新的以时间命令的目录以存放所有的增量备份数据。
另外,在执行过增量备份之后再一次进行增量备份时,其--incremental-basedir应该指向上一次的增量备份所在的目录,
以此类推。。。。

注意:需要特别指出的是,增量备份仅能应用于InnoDB或XtraDB表,对于MyISAM表而言,执行增量备份时其实进行的是完全备份

下面是一个在完全备份基础上的第一次增量备份(时间是2017年0517)

#innobackupex --user=root --password=123456 --socket=/opt/app/mysql5/var/mysql.sock --incremental /backup --incremental-basedir=/backup/2017-05-16_23-43-42/
170517 01:41:37 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

170517 01:41:37  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/opt/app/mysql5/var/mysql.sock' as 'root'  (using password: YES).
170517 01:41:37  version_check Connected to MySQL server
170517 01:41:37  version_check Executing a version check against the server...
170517 01:41:37  version_check Done.
170517 01:41:37 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: /opt/app/mysql5/var/mysql.sock
Using server version 5.6.34-log
innobackupex version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 6f7a799)
incremental backup from 3040636 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /opt/app/mysql5/var/
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = /opt/app/mysql5/varinnodb
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = /opt/app/mysql5/varinnodb
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 536870912
InnoDB: Number of pools: 1
170517 01:41:37 >> log scanned up to (3135893)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 4 for mysql/slave_master_info, old maximum was 0
xtrabackup: using the full scan for incremental backup
170517 01:41:39 >> log scanned up to (3135893)
170517 01:41:39 [01] Copying /opt/app/mysql5/varinnodb/ibdata1 to /backup/2017-05-17_01-41-37/ibdata1.delta
170517 01:41:40 >> log scanned up to (3135893)
170517 01:41:40 [01]        ...done
170517 01:41:41 [01] Copying ./mysql/slave_master_info.ibd to /backup/2017-05-17_01-41-37/mysql/slave_master_info.ibd.delta
170517 01:41:41 [01]        ...done
………………
170517 01:41:44 Finished backing up non-InnoDB tables and files
170517 01:41:44 [00] Writing xtrabackup_binlog_info
170517 01:41:44 [00]        ...done
170517 01:41:44 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '3135893'
xtrabackup: Stopping log copying thread.
.170517 01:41:44 >> log scanned up to (3135893)

170517 01:41:44 Executing UNLOCK TABLES
170517 01:41:44 All tables unlocked
170517 01:41:44 Backup created in directory '/backup/2017-05-17_01-41-37/'
MySQL binlog position: filename 'bin-log.000006', position '119398'
170517 01:41:44 [00] Writing backup-my.cnf
170517 01:41:44 [00]        ...done
170517 01:41:44 [00] Writing xtrabackup_info
170517 01:41:44 [00]        ...done
xtrabackup: Transaction log of lsn (3135893) to (3135893) was copied.
170517 01:41:44 completed OK!

整理(prepare)增量备份与整理完全备份是不同的,尤其要注意是:

a、需要在每个备份(包括完全和各个增量备份)上,将已经提交的事务进行“重放”。“重放”之后,所有的备份数据将合并到完全备份上。

b、基于所有的备份将未提交的事务进行“回滚”。

于是,操作就变成了:

#innobackupex --apply-log --redo-only BASE-DIR    (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    --开始第二个增量备份
基于完全备份的数据还原:
#innobackupex --copy-back  /path/to/BASE-DIR (此时的BASE-DIR目录是整理完完全备份和增量备份之后合并的目录)

演示三:完全备份+增量备份以及数据的还原:

(1).首先进行完全备份,进行增量备份之前要做一次完全备份的,过程和上面的实现过程一样:

为了显示效果,将上一步骤中的完全备份的结果删除,重新全备:

#rm -rf /backup/*
完全备份:
#innobackupex --user=root --password=redhat /backup 显示信息和上面此操作的信息一样:

为了演示增量备份的效果,使用一个脚本自动向数据库中的某个表中插入数据,此处的数据库为jiaowu,表为students,说明此时如果有事务正在进行一些操作也不影响增量备份的,脚本如下:

#cat insert_sql.sh
#!/bin/bash
MYSQL='mysql -uroot -predhat'

for I in {3501..4500}; do
  CID1=$[$RANDOM%500+1]
  CID2=$[$RANDOM%500+1]
  TID=$[$RANDOM%100+1]
  while [ $CID1 -eq $CID2 ]; do
      CID2=$[$RANDOM%500+1]
  done
  [ $[$RANDOM%2] -eq 0 ] && GENDER='M' || GENDER='F'

  TIMESTAMP=$[$RANDOM*$RANDOM]
  sleep 1
  $MYSQL -e "INSERT INTO jiaowu.students (Name,Age,Gender,CID1,CID2,TID,BirthDate,ExtraInfo) VALUES ('stu$I',YEAR(now())-YEAR(FROM_UNIXTIME($TIMESTAMP)),'$GENDER',$CID1,$CID2,$TID,FROM_UNIXTIME($TIMESTAMP),'A student\,stu$I\,$GENDER\,Good person\.');" > /dev/null 2>&1 
done

脚本运行之后就会自动在jiaowu数据库中的students表中插入数据了,如下图所示:

此时表中的数据已经开始在增加了:

(2)进行第一次增量备份:

#innobackupex --user=root --password=redhat --incremental /backup --incremental-dir=/backup/2012-03-18_03-20-40/
注:/backup/2012-03-18_03-20-40/ 此目录是完全备份后自动生成的那个以时间命名的目录。

如下图:

进行第二次增量备份:

#innobackupex --user=root --password=redhat --incremental /backup --incremental-dir=/backup/2012-03-18_03-30-58/
注:/backup/2012-03-18_03-30-58是第一次增量备份后,生成的目录

如下图:

进行第三次增量备份:

#innobackupex --user=root --password=redhat --incremental /backup --incremental-dir=/backup/2012-03-18_03-35-40/
注:/backup/2012-03-18_03-35-40/ 是第二次增量备份后,生成的目录

如下图:

此时模拟mysql服务器出现故障,先将自动向表中插入数据的脚本关闭掉:如下图所示:

然后记录一下插入了多少数据,此时数据已经插入到了1642,如:stu1642

(3)然后对二进制日志文件进行备份:只备份最后一次增量备份后那个事件位置往后的数据即可。如下图:

#mysqlbinlog --start-position=227066  /mydata/data/mysql-bin.000002 > /tmp/mydatabak.sql

然后模拟数据库损坏,此处直接将数据库中的数据全部删除(注意,在全部删除之前确保最近一次的二进制日志文件已经备份,以实现及时点恢复)

#service mysqld stop 
#rm -rf /mydata/data/*

开始恢复,步骤如下:

(4)准备(prepare)完全备份:

#innobackupex --apply-log --redo-only /backup/2012-03-18_03-20-40/

(5).准备(prepare)增量备份:

第一次增量备份
#innobackupex --apply-log --redo-only /backup/2012-03-18_03-20-40/ --incremental-dir=/backup/2012-03-18_03-30-58/
第二次增量备份
#innobackupex --apply-log --redo-only /backup/2012-03-18_03-20-40/ --incremental-dir=/backup/2012-03-18_03-35-40/
第三次增量备份
#innobackupex --apply-log --redo-only /backup/2012-03-18_03-20-40/ --incremental-dir=/backup/2012-03-18_03-38-11/

(6).恢复数据: 

#innobackupex --copy-back /backup/2012-03-18_03-20-40/

恢复成功会出现如下图所示信息:

#chown -R mysql.mysql /mydata/data    --修改mysql数据目录的属主和属组
#service mysqld start 
#service mysqld restart               --如果重启成功则说明数据恢复已经成功完成

此时的数据库中信息如下图所示:

(7).做及时点恢复,导入备份的二进制日志文件:

#mysql -uroot -predhat
mysql> set sql_log_bin=0;         --先将二进制日志暂时关闭,避免使用source命令的时候产生无用的日志信息:
mysql> source /tmp/mydatabak.sql  --将备份的二进制日志导入数据库:
mysql> set sql_log_bin=1;         --然后再将二进制日志开启;

增加的一部分数据,如下图所示:此数据就是最后一次增量备份之后,关闭自动插入数据的脚本之前产生的那段数据:

说明:

使用xtrabackup物理备份可以实现全备和增量备份,但是恢复的时候,需要将mysql数据存放目录里面的内容全部删除,然后整体恢复。这种情况无法满足误删除某一张表时候的恢复,除非是先将数据完全恢复到一台备用服务器上,然后使用mysqldump备份误删除的表,然后再恢复误删除的表,这样的话就比较耗费时间,所以需要根据自己的实际环境选择备份方式!

#######################################################################

(8)、在slave服务器使用xtrabackup备份

#nohup time innobackupex --defaults-file=/opt/app/mysql/etc/my.cnf -uroot -pxxxxx --slave-info --parallel=20  ./ &
备份好之后,打包
#nohup time tar -c 2017-10-09_17-14-13/ | pbzip2 -c > mysql_data_2017-10-09.tar.bz2 &
参数介绍:
--slave-info  备份复制从服务端,主从信息记录在ibbackup_slave_info文件中
--parallel=#  默认为1.传输数据文件的并行线程数,没有任何流模式的影响
--target-dir=name 目的目录,默认目录在./xtrabackup_backupfiles/,相对于datadir目录

不足之处,请多多指出!