1）介绍

PerconaXtraBackup（简称PXB）是Percona公司开发的一个用于MySQL数据库物理热备的备份工具，支持MySQl（Oracle）、Percona Server和MariaDB，并且全部开源，真可谓是业界良心。能够为InnoDB和XtraDB数据库执行非阻塞备份，特点如下：

1、快速、可靠的完成备份

2、备份期间不间断事务处理

3、节省磁盘空间和网络带宽

4、自动对备份文件进行验证

5、恢复快，保障在线运行时间持久性

percona-xtrabackup软件包中中包含了两个工具，一个是xtrabackup，另一个是innobackupex，innobackupex由per进行封装，在对innodb表进行备份时会自动调用xtraback工具，所以对InnoDB表做备份的实际是xtrabackup这个工具，xtrabackup也只能对innodb表做备份，这是一个专门对innodb开发的热备工具，而对myisam这样的其他引擎的表则由innobackupex来负责备份，若是全备份加增量的方案，那每次增量innobackupex工具对非innodb表都是全备份且会请求读锁。

xtrabackup对innodb表进行备份时不再只是简单复制文件，而是利用在innodb存储引擎层中的LSN（日志序列号）的新旧来识别这一数据页是否需要备份。

xtraback工具对innodb引擎完美支持真正的热备份，备份好的数据中数据文件与事务日志的文件因innodb cache等因素的存在，所以备份好的数据和事务日志中的数据往往是不一致的，所以，在做数据恢复时需要把事务日志中已提交的事务做redo，没有提交的事务做undo操作，这就是在做数据恢复时要做的准备工作，即prepare。

2）Xtrabackup备份原理

1、InnoDB的备份原理

在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。

备份过程

Xtrabackup在启动时会记住log

sequence number（LSN），并且复制所有的数据文件。复制过程需要一些时间，所以这期间如果数据文件有改动，那么将会使数据库处于一个不同的时间点。这时，xtrabackup会运行一个后台进程，用于监视事务日志，并从事务日志复制最新的修改。Xtrabackup必须持续的做这个操作，是因为事务日志是会轮转重复的写入，并且事务日志可以被重用。所以xtrabackup自启动开始，就不停的将事务日志中每个数据文件的修改都记录下来。

准备过程

上面就是xtrabackup的备份过程。接下来是准备（prepare）过程。在这个过程中，xtrabackup使用之前复制的事务日志，对各个数据文件执行灾难恢复（就像mysql刚启动时要做的一样）。当这个过程结束后，数据库就可以做恢复还原了。

2、MyISAM的备份原理

以上的过程在xtrabackup的编译二进制程序中实现。程序innobackupex可以允许我们备份MyISAM表和frm文件从而增加了便捷和功能。Innobackupex会启动xtrabackup，直到xtrabackup复制数据文件后，然后执行FLUSH TABLES WITH READ LOCK来阻止新的写入进来并把MyISAM表数据刷到硬盘上，之后复制MyISAM数据文件，最后释放锁。

备份MyISAM和InnoDB表最终会处于一致，在准备（prepare）过程结束后，InnoDB表数据已经前滚到整个备份结束的点，而不是回滚到xtrabackup刚开始时的点。这个时间点与执行FLUSH TABLES WITH READ LOCK的时间点相同，所以myisam表数据与InnoDB表数据是同步的。类似oracle的，InnoDB的prepare过程可以称为recover（恢复），myisam的数据复制过程可以称为restore（还原）。

Xtrabackup和innobackupex这两个工具都提供了许多前文没有提到的功能特点。手册上有对各个功能都有详细的介绍。简单介绍下，这些工具提供了如流（streaming）备份，增量（incremental）备份等，通过复制数据文件，复制日志文件和提交日志到数据文件（前滚）实现了各种复合备份方式。

3）、安装

1、使用yum方式安装

配置仓库

yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm-y

检查仓库

yum list | grep percona

安装包

yum install percona-xtrabackup-24

2、使用rpm包安装

下载rpm包

wgethttps://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

安装：

yum localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

3、安装后的目录结构

4）通信方式

2个工具之间的交互和协调是通过控制文件的创建和删除来实现的，主要文件有：

xtrabackup_suspended_1

xtrabackup_suspended_2

xtrabackup_log_copied

举个栗子，我们来看备份时xtrabackup_suspended_2是怎么来协调2个工具进程的

innobackupex在启动xtrabackup进程后，会一直等xtrabackup备份完InnoDB文件，方式就是等待xtrabackup_suspended_2这个文件被创建出来；

xtrabackup在备完InnoDB数据后，就在指定目录下创建出这个文件，然后等这个文件被innobackupex删除；

innobackupex检测到文件xtrabackup_suspended_2被创建出来后，就继续往下走；

innobackupex在备份完非InnoDB表后，删除xtrabackup_suspended_2这个文件，这样就通知xtrabackup可以继续了，然后等xtrabackup_log_copied被创建；

xtrabackup检测到xtrabackup_suspended_2文件删除后，就可以继续往下了。

5）备份过程

innobackupex在启动后，会先fork一个进程，启动xtrabackup进程，然后就等待xtrabackup备份完ibd数据文件；

xtrabackup在备份InnoDB相关数据时，是有2种线程的，1种是redo拷贝线程，负责拷贝redo文件，1种是ibd拷贝线程，负责拷贝ibd文件；redo拷贝线程只有一个，在ibd拷贝线程之前启动，在ibd线程结束后结束。xtrabackup进程开始执行后，先启动redo拷贝线程，从最新的checkpoint点开始顺序拷贝redo日志；然后再启动ibd数据拷贝线程，在xtrabackup拷贝ibd过程中，innobackupex进程一直处于等待状态（等待文件被创建）。

xtrabackup拷贝完成idb后，通知innobackupex（通过创建文件），同时自己进入等待（redo线程仍然继续拷贝）;

innobackupex收到xtrabackup通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非InnoDB文件（包括frm、MYD、MYI、CSV、opt、par等）。拷贝非InnoDB文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非InnoDB表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。

当innobackupex拷贝完所有非InnoDB表文件后，通知xtrabackup（通过删文件），同时自己进入等待（等待另一个文件被创建）；

xtrabackup收到innobackupex备份完非InnoDB通知后，就停止redo拷贝线程，然后通知innobackupex redo log拷贝完成（通过创建文件）；

innobackupex收到redo备份完成通知后，就开始解锁，执行UNLOCK TABLES；

最后innobackupex和xtrabackup进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex等待xtrabackup子进程结束后退出。

在上面描述的文件拷贝，都是备份进程直接通过操作系统读取数据文件的，只在执行SQL命令时和数据库有交互，基本不影响数据库的运行，在备份非InnoDB时会有一段时间只读（如果没有MyISAM表的话，只读时间在几秒左右），在备份InnoDB数据文件时，对数据库完全没有影响，是真正的热备。

InnoDB和非InnoDB文件的备份都是通过拷贝文件来做的，但是实现的方式不同，前者是以page为粒度做的(xtrabackup)，后者是cp或者tar命令(innobackupex)，xtrabackup在读取每个page时会校验checksum值，保证数据块是一致的，而innobackupex在cp MyISAM文件时已经做了flush（FTWRL），磁盘上的文件也是完整的，所以最终备份集里的数据文件都是写入完整的。

6）增量备份

PXB是支持增量备份的，但是只能对InnoDB做增量，InnoDB每个page有个LSN号，LSN是全局递增的，page被更改时会记录当前的LSN号，page中的LSN越大，说明当前page越新（最近被更新）。每次备份会记录当前备份到的LSN（xtrabackup_checkpoints文件中），增量备份就是只拷贝LSN大于上次备份的page，比上次备份小的跳过，每个ibd文件最终备份出来的是增量delta文件。

MyISAM是没有增量的机制的，每次增量备份都是全部拷贝的。

增量备份过程和全量备份一样，只是在ibd文件拷贝上有不同。

7）恢复过程

如果看恢复备份集的日志，会发现和mysqld启动时非常相似，其实备份集的恢复就是类似mysqld crash后，做一次crash recover。

恢复的目的是把备份集中的数据恢复到一个一致性位点，所谓一致就是指原数据库某一时间点各引擎数据的状态，比如MyISAM中的数据对应的是15:00时间点的，InnoDB中的数据对应的是15:20的，这种状态的数据就是不一致的。PXB备份集对应的一致点，就是备份时FTWRL的时间点，恢复出来的数据，就对应原数据库FTWRL时的状态。

因为备份时FTWRL后，数据库是处于只读的，非InnoDB数据是在持有全局读锁情况下拷贝的，所以非InnoDB数据本身就对应FTWRL时间点；InnoDB的ibd文件拷贝是在FTWRL前做的，拷贝出来的不同ibd文件最后更新时间点是不一样的，这种状态的ibd文件是不能直接用的，但是redo log是从备份开始一直持续拷贝的，最后的redo日志点是在持有FTWRL后取得的，所以最终通过redo应用后的ibd数据时间点也是和FTWRL一致的。

所以恢复过程只涉及InnoDB文件的恢复，非InnoDB数据是不动的。备份恢复完成后，就可以把数据文件拷贝到对应的目录，然后通过mysqld来启动了

8）备份实例

1、全量备份

[root@linux-node2 backups]#xtrabackup –backup

–target-dir=/data/backups/$(date +%F) -uroot -p123456

170427 10:46:41version_check Connecting to MySQL server withDSN’dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock’as ‘root'(using password: YES).

170427 10:46:41version_check Connected to MySQL server

170427 10:46:41version_check Executing a version checkagainst the server…

170427 10:46:41version_check Done.

170427 10:46:41 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock

Using server version 5.6.35-log

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /usr/local/mysql/data

xtrabackup: open files limit requested 65535,set to 1024000

xtrabackup: using the following InnoDBconfiguration:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = ./

xtrabackup:innodb_log_files_in_group = 2

xtrabackup:innodb_log_file_size = 536870912

InnoDB: Number of pools: 1

170427 10:46:41 >> log scanned up to(1743474)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0

170427 10:46:41 [01] Copying ./ibdata1 to/data/backups/2017-04-27/ibdata1

170427 10:46:41 [01]…done

170427 10:46:41 [01] Copying./mysql/slave_master_info.ibd to/data/backups/2017-04-27/mysql/slave_master_info.ibd

170427 10:46:41 [01]…done

170427 10:46:41 [01] Copying./mysql/slave_relay_log_info.ibd to/data/backups/2017-04-27/mysql/slave_relay_log_info.ibd

170427 10:46:41 [01]…done

…………

170427 10:46:42 [01] Copying ./test/db.opt to/data/backups/2017-04-27/test/db.opt

170427 10:46:42 [01]…done

170427 10:46:42 Finished backing upnon-InnoDB tables and files

170427 10:46:42 [00] Writingxtrabackup_binlog_info

170427 10:46:42 [00]…done

170427 10:46:42 Executing FLUSHNO_WRITE_TO_BINLOG ENGINE LOGS…

xtrabackup: The latest check point (forincremental): ‘1743474’

xtrabackup: Stopping log copying thread.

.170427 10:46:42 >> log scanned up to(1743474)

170427 10:46:43 Executing UNLOCK TABLES

170427 10:46:43 All tables unlocked

170427 10:46:43 Backup created in directory’/data/backups/2017-04-27/’

MySQL binlog position: filename’mysql-bin.000004′, position ‘191’, GTID of the last change’0e9896a7-14f7-11e7-a0e6-000c2900551e:1-3′

170427 10:46:43 [00] Writing backup-my.cnf

170427 10:46:43 [00]…done

170427 10:46:43 [00] Writing xtrabackup_info

170427 10:46:43 [00]…done

xtrabackup: Transaction log of lsn (1743474)to (1743474) was copied.

170427 10:46:43 completed OK!#表示备份成功。

[root@linux-node2 backups]#

备份成功后，备份目录的结构如下：

2、增量备份

[root@linux-node2 backups]# xtrabackup–backup –target-dir=/data/backups/increment/$(date +%F-%H-%M-%S)–incremental-basedir=/data/backups/2017-04-27/ -uroot -p123456

170427 14:41:49version_check Connecting to MySQL server withDSN’dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock’as ‘root'(using password: YES).

170427 14:41:49version_check Connected to MySQL server

170427 14:41:49version_check Executing a version checkagainst the server…

170427 14:41:49version_check Done.

170427 14:41:49 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock

Using server version 5.6.35-log

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

incremental backup from 1743474 is enabled.

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /usr/local/mysql/data

xtrabackup: open files limit requested 65535,set to 1024000

xtrabackup: using the following InnoDBconfiguration:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = ./

xtrabackup:innodb_log_files_in_group = 2

xtrabackup:innodb_log_file_size = 536870912

InnoDB: Number of pools: 1

170427 14:41:49 >> log scanned up to(1752524)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0

xtrabackup: using the full scan forincremental backup

170427 14:41:49 [01] Copying ./ibdata1 to/data/backups/increment/2017-04-27-14-41-49/ibdata1.delta

170427 14:41:49 [01]…done

170427 14:41:49 [01] Copying./mysql/slave_master_info.ibd to /data/backups/increment/2017-04-27-14-41-49/mysql/slave_master_info.ibd.delta

170427 14:41:49 [01]…done

170427 14:41:49 [01] Copying./mysql/slave_relay_log_info.ibd to/data/backups/increment/2017-04-27-14-41-49/mysql/slave_relay_log_info.ibd.delta

…………

170427 14:41:50 [01] Copying./incrememtal1/t1.frm to/data/backups/increment/2017-04-27-14-41-49/incrememtal1/t1.frm

170427 14:41:50 [01]…done

170427 14:41:50 Finished backing upnon-InnoDB tables and files

170427 14:41:50 [00] Writing xtrabackup_binlog_info

170427 14:41:50 [00]…done

170427 14:41:50 Executing FLUSHNO_WRITE_TO_BINLOG ENGINE LOGS…

xtrabackup: The latest check point (forincremental): ‘1752524’

xtrabackup: Stopping log copying thread.

.170427 14:41:50 >> log scanned up to(1752524)

170427 14:41:50 Executing UNLOCK TABLES

170427 14:41:50 All tables unlocked

170427 14:41:50 Backup created in directory’/data/backups/increment/2017-04-27-14-41-49/’

MySQL binlog position: filename’mysql-bin.000004′, position ‘525’, GTID of the last change’0e9896a7-14f7-11e7-a0e6-000c2900551e:1-5′

170427 14:41:50 [00] Writing backup-my.cnf

170427 14:41:50 [00]…done

170427 14:41:50 [00] Writing xtrabackup_info

170427 14:41:50 [00]…done

xtrabackup: Transaction log of lsn (1752524)to (1752524) was copied.

170427 14:41:50 completed OK!

备份成功后的目录结构：

查看xtrabackup_checkpoints文件，显示备份是从lsn

1743474到lsn 1752524，通过查看上一次全量备份目录的xtrabackup_checkpoints文件显示，最后一个lsn是1743474。

[root@linux-node22017-04-27-14-41-49]# cat xtrabackup_checkpoints

backup_type = incremental

from_lsn = 1743474

to_lsn = 1752524

last_lsn = 1752524

compact = 0

recover_binlog_info = 0

[root@linux-node2 2017-04-27-14-41-49]#

3、再次增量备份（基于上一次增量备份）

[root@linux-node2 increment]# xtrabackup–backup –target-dir=/data/backups/increment/$(date +%F-%H-%M-%S)–incremental-basedir=/data/backups/increment/2017-04-27-14-41-49/ -uroot-p123456

170427 15:39:26version_check Connecting to MySQL server withDSN ‘dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock’as ‘root'(using password: YES).

170427 15:39:26version_check Connected to MySQL server

170427 15:39:26version_check Executing a version checkagainst the server…

170427 15:39:26version_check Done.

170427 15:39:26 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock

Using server version 5.6.35-log

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

incremental backup from 1752524 is enabled.

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /usr/local/mysql/data

xtrabackup: open files limit requested 65535,set to 1024000

xtrabackup: using the following InnoDBconfiguration:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = ./

xtrabackup:innodb_log_files_in_group = 2

xtrabackup:innodb_log_file_size = 536870912

InnoDB: Number of pools: 1

170427 15:39:26 >> log scanned up to(1758973)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0

xtrabackup: using the full scan forincremental backup

170427 15:39:26 [01] Copying ./ibdata1 to/data/backups/increment/2017-04-27-15-39-25/ibdata1.delta

170427 15:39:26 [01]…done

……

170427 15:39:26 [01] Copying./incrememtal2/t1.ibd to/data/backups/increment/2017-04-27-15-39-25/incrememtal2/t1.ibd.delta

170427 15:39:26 [01]…done

170427 15:39:27 >> log scanned up to(1758973)

170427 15:39:27 Executing FLUSHNO_WRITE_TO_BINLOG TABLES…

170427 15:39:27 Executing FLUSH TABLES WITHREAD LOCK…

170427 15:39:27 Starting to backup non-InnoDBtables and files

170427 15:39:27 [01] Copying./mysql/servers.frm to/data/backups/increment/2017-04-27-15-39-25/mysql/servers.frm

170427 15:39:27 [01]…done

……

170427 15:39:27 [01] Copying./incrememtal2/t1.frm to /data/backups/increment/2017-04-27-15-39-25/incrememtal2/t1.frm

170427 15:39:27 [01]…done

170427 15:39:27 Finished backing upnon-InnoDB tables and files

170427 15:39:27 [00] Writingxtrabackup_binlog_info

170427 15:39:27 [00]…done

170427 15:39:27 Executing FLUSH NO_WRITE_TO_BINLOGENGINE LOGS…

xtrabackup: The latest check point (forincremental): ‘1758973’

xtrabackup: Stopping log copying thread.

.170427 15:39:27 >> log scanned up to(1758973)

170427 15:39:27 Executing UNLOCK TABLES

170427 15:39:27 All tables unlocked

170427 15:39:27 Backup created in directory’/data/backups/increment/2017-04-27-15-39-25/’

MySQL binlog position: filename’mysql-bin.000004′, position ‘859’, GTID of the last change’0e9896a7-14f7-11e7-a0e6-000c2900551e:1-7′

170427 15:39:27 [00] Writing backup-my.cnf

170427 15:39:27 [00]…done

170427 15:39:27 [00] Writing xtrabackup_info

170427 15:39:27 [00]…done

xtrabackup: Transaction log of lsn (1758973)to (1758973) was copied.

170427 15:39:27 completed OK!

查看备份完成后的目录结构：

4、准备恢复（preparing a backup）-基于全量备份

在在使用备份文件恢复数据之前，你需要对备份的数据进行整理。具体原因在前面的内容已经介绍过，我们先看使用完全备份恢复

[root@linux-node2 2017-04-27-15-39-25]#xtrabackup –prepare –target-dir=/data/backups/2017-04-27/

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

xtrabackup: cd to /data/backups/2017-04-27/

xtrabackup: This target seems to be notprepared yet.

InnoDB: Number of pools: 1

xtrabackup: xtrabackup_logfile detected:size=8388608, start_lsn=(1743474)

xtrabackup: using the following InnoDBconfiguration for recovery:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = .

xtrabackup:innodb_log_files_in_group = 1

xtrabackup:innodb_log_file_size = 8388608

xtrabackup: using the following InnoDBconfiguration for recovery:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = .

xtrabackup:innodb_log_files_in_group = 1

xtrabackup:innodb_log_file_size = 8388608

xtrabackup: Starting InnoDB instance forrecovery.

xtrabackup: Using 104857600 bytes for bufferpool (set by –use-memory parameter)

InnoDB: PUNCH HOLE support available

InnoDB: Mutexes and rw_locks use GCC atomicbuiltins

InnoDB: Uses event mutexes

InnoDB: GCC builtin __atomic_thread_fence()is used for memory barrier

InnoDB: Compressed tables use zlib 1.2.7

InnoDB: Number of pools: 1

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, total size= 100M, instances = 1, chunk size = 100M

InnoDB: Completed initialization of bufferpool

InnoDB: page_cleaner coordinator priority:-20

InnoDB: Highest supported file format isBarracuda.

InnoDB: The log sequence number 1732944 in thesystem tablespace does not match the log sequence number 1743474 in theib_logfiles!

InnoDB: Database was not shutdown normally!

InnoDB: Starting crash recovery.

InnoDB: Doing recovery: scanned up to logsequence number 1743474 (0%)

InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002

InnoDB: Creating shared tablespace fortemporary tables

InnoDB: Setting file ‘./ibtmp1’ size to 12MB. Physically writing the file full; Please wait …

InnoDB: File ‘./ibtmp1’ size is now 12 MB.

InnoDB: 96 redo rollback segment(s) found. 1redo rollback segment(s) are active.

InnoDB: 32 non-redo rollback segment(s) areactive.

InnoDB: Waiting for purge to start

InnoDB: 5.7.13 started; log sequence number1743474

InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002

xtrabackup: starting shutdown withinnodb_fast_shutdown = 1

InnoDB: FTS optimize thread exiting.

InnoDB: Starting shutdown…

InnoDB: Shutdown completed; log sequencenumber 1743493

InnoDB: Number of pools: 1

xtrabackup: using the following InnoDBconfiguration for recovery:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = .

xtrabackup:innodb_log_files_in_group = 2

xtrabackup:innodb_log_file_size = 536870912

InnoDB: PUNCH HOLE support available

InnoDB: Mutexes and rw_locks use GCC atomicbuiltins

InnoDB: Uses event mutexes

InnoDB: GCC builtin __atomic_thread_fence()is used for memory barrier

InnoDB: Compressed tables use zlib 1.2.7

InnoDB: Number of pools: 1

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, total size= 100M, instances = 1, chunk size = 100M

InnoDB: Completed initialization of bufferpool

InnoDB: page_cleaner coordinator priority:-20

InnoDB: Setting log file ./ib_logfile101 sizeto 512 MB

InnoDB: Progress in MB:

100200 300 400 500

InnoDB: Setting log file ./ib_logfile1 sizeto 512 MB

InnoDB: Progress in MB:

100200 300 400 500

InnoDB: Renaming log file ./ib_logfile101 to./ib_logfile0

InnoDB: New log files created, LSN=1743493

InnoDB: Highest supported file format isBarracuda.

InnoDB: Log scan progressed past thecheckpoint lsn 1743884

InnoDB: Doing recovery: scanned up to logsequence number 1743893 (0%)

InnoDB: Doing recovery: scanned up to logsequence number 1743893 (0%)

InnoDB: Database was not shutdown normally!

InnoDB: Starting crash recovery.

InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002

InnoDB: Removed temporary tablespace datafile: “ibtmp1”

InnoDB: Creating shared tablespace fortemporary tables

InnoDB: Setting file ‘./ibtmp1’ size to 12MB. Physically writing the file full; Please wait …

InnoDB: File ‘./ibtmp1’ size is now 12 MB.

InnoDB: 96 redo rollback segment(s) found. 1redo rollback segment(s) are active.

InnoDB: 32 non-redo rollback segment(s) areactive.

InnoDB: Waiting for purge to start

InnoDB: 5.7.13 started; log sequence number1743893

xtrabackup: starting shutdown withinnodb_fast_shutdown = 1

InnoDB: FTS optimize thread exiting.

InnoDB: Starting shutdown…

InnoDB: page_cleaner: 1000ms intended looptook 4725ms. The settings might not be optimal. (flushed=0 and evicted=0,during the time.)

InnoDB: Shutdown completed; log sequencenumber 1743912

170427 15:52:06 completed OK!

如果已经进行过数据整理，再次运行会有如下提示信息：

xtrabackup: This target seems to be alreadyprepared.

xtrabackup: notice: xtrabackup_logfile wasalready used to ‘–prepare’.

5、恢复备份（基于全量）

首先我们需要所整理完数据后的备份目录内的文件复制到mysql的数据目录，复制的方法很多，可以使用xtrabackup –copy-back选项，或者—move-back选项，当然我们也可以使用rsync或者cp等命令。（注意在操作前应该先停止mysql服务，然后清空数据目录）

[root@linux-node2 mysql]# mysqladmin -uroot-p123456 shutdown

Warning: Using a password on the command lineinterface can be insecure.

[root@linux-node2 mysql]# 170427 16:11:27mysqld_safe mysqld from pid file /usr/local/mysql/data/db01.pid ended

[1]+Done/usr/local/mysql/bin/mysqld_safe(wd: ~)

(wd now: /usr/local/mysql)

[root@linux-node2 mysql]# mv /usr/local/mysql/data/tmp/

完成后使用xtraback恢复数据

[root@linux-node2 mysql]# xtrabackup–copy-back –target-dir=/data/backups/2017-04-27/

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

170427 16:13:43 [01] Copying ib_logfile0 to /usr/local/mysql/data/ib_logfile0

170427 16:13:46 [01]…done

170427 16:13:46 [01] Copying ib_logfile1 to/usr/local/mysql/data/ib_logfile1

170427 16:13:48 [01]…done

…………

170427 16:13:49 [01]…done

170427 16:13:49 [01] Copying ./xtrabackup_infoto /usr/local/mysql/data/xtrabackup_info

170427 16:13:49 [01]…done

170427 16:13:49 [01] Copying./xtrabackup_binlog_pos_innodb to/usr/local/mysql/data/xtrabackup_binlog_pos_innodb

170427 16:13:49 [01]…done

170427 16:13:49 [01] Copying ./ibtmp1 to/usr/local/mysql/data/ibtmp1

170427 16:13:49 [01]…done

170427 16:13:49 completed OK!

对恢复后的文件授权：

[root@linux-node2

mysql]# chown -R mysql.mysql /usr/local/mysql/data/

最后重启启动mysql服务

[root@linux-node2data]# Logging to ‘/usr/local/mysql/data/mysql-error.log’.

17042716:15:08 mysqld_safe Starting mysqld daemon with databases from/usr/local/mysql/data

[root@linux-node2data]# lsof -i :3306

COMMANDPIDUSERFDTYPE DEVICE SIZE/OFF NODE NAME

mysqld4116 mysql13uIPv6260840t0TCP *:mysql (LISTEN)

[root@linux-node2data]# mysql -uroot -p

Enterpassword:

Welcome tothe MySQL monitor.Commands end with ;or \g.

Your MySQLconnection id is 1

Serverversion: 5.6.35-log MySQL Community Server (GPL)

Copyright(c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle isa registered trademark of Oracle Corporation and/or its

affiliates.Other names may be trademarks of their respective

owners.

Type’help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql>show databases;

+——————–+

|Database|

+——————–+

|information_schema |

|mysql|

|performance_schema |

|test|

+——————–+

4 rows inset (0.00 sec)

6、基于增量备份进行恢复

我们现在的备份情况如下：

/data/backups/2017-04-27全备

[root@linux-node2 backups]# cat 2017-04-27/xtrabackup_checkpoints

backup_type = full-backuped

from_lsn = 0

to_lsn = 1780797

last_lsn = 1780797

compact = 0

recover_binlog_info = 0

/data/backups/increment/2017-04-27-16-51-43第一次增备

[root@linux-node2 backups]# catincrement/2017-04-27-16-51-43/xtrabackup_checkpoints

backup_type = incremental

from_lsn = 1780797

to_lsn = 1788921

last_lsn = 1788921

compact = 0

recover_binlog_info = 0

/data/backups/increment/2017-04-27-16-52-18第二次增备

[root@linux-node2 backups]# catincrement/2017-04-27-16-52-18/xtrabackup_checkpoints

backup_type = incremental

from_lsn = 1788921

to_lsn = 1796758

last_lsn = 1796758

compact = 0

recover_binlog_info = 0

恢复过程如下：

使用全备进行恢复准备操作，

[root@linux-node2 backups]# xtrabackup–prepare –apply-log-only –target-dir=/data/backups/2017-04-27/

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

xtrabackup: cd to /data/backups/2017-04-27/

xtrabackup: This target seems to be notprepared yet.

InnoDB: Number of pools: 1

xtrabackup: xtrabackup_logfile detected:size=8388608, start_lsn=(1780797)

xtrabackup: using the following InnoDBconfiguration for recovery:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = .

xtrabackup:innodb_log_files_in_group = 1

xtrabackup:innodb_log_file_size = 8388608

xtrabackup: using the following InnoDBconfiguration for recovery:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = .

xtrabackup:innodb_log_files_in_group = 1

xtrabackup:innodb_log_file_size = 8388608

xtrabackup: Starting InnoDB instance forrecovery.

xtrabackup: Using 104857600 bytes for bufferpool (set by –use-memory parameter)

InnoDB: PUNCH HOLE support available

InnoDB: Mutexes and rw_locks use GCC atomicbuiltins

InnoDB: Uses event mutexes

InnoDB: GCC builtin __atomic_thread_fence()is used for memory barrier

InnoDB: Compressed tables use zlib 1.2.7

InnoDB: Number of pools: 1

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, total size= 100M, instances = 1, chunk size = 100M

InnoDB: Completed initialization of bufferpool

InnoDB: page_cleaner coordinator priority:-20

InnoDB: Highest supported file format isBarracuda.

InnoDB: The log sequence number 1761000 inthe system tablespace does not match the log sequence number 1780797 in theib_logfiles!

InnoDB: Database was not shutdown normally!

InnoDB: Starting crash recovery.

InnoDB: Doing recovery: scanned up to logsequence number 1780797 (0%)

InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002

InnoDB: xtrabackup: Last MySQL binlog fileposition 1169, file name master-bin.000002

xtrabackup: starting shutdown withinnodb_fast_shutdown = 1

InnoDB: Starting shutdown…

InnoDB: Shutdown completed; log sequencenumber 1780806

InnoDB: Number of pools: 1

170427 16:55:24 completed OK!

合并第一次增备

[root@linux-node2 backups]# xtrabackup–prepare –apply-log-only –target-dir=/data/backups/2017-04-27/–incremental-dir=/data/backups/increment/2017-04-27-16-51-43/

合并第二次增备：

[root@linux-node2 backups]# xtrabackup–prepare –target-dir=/data/backups/2017-04-27/ –incremental-dir=/data/backups/increment/2017-04-27-16-52-18/

合并完成后，使用上面第五步的方法恢复数据库。

9）压缩备份（compressed backup）

XtraBackup支持压缩备份

1、创建Compressed Backups

[root@linux-node2 backups]# xtrabackup–backup –compress –target-dir=/data/backups/compressed/$(date +%F) -uroot-p123456

170427 17:28:03version_check Connecting to MySQL server withDSN ‘dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/usr/local/mysql/data/mysqld.sock’as ‘root'(using password: YES).

170427 17:28:03version_check Connected to MySQL server

170427 17:28:03version_check Executing a version checkagainst the server…

170427 17:28:03version_check Done.

170427 17:28:03 Connecting to MySQL serverhost: localhost, user: root, password: set, port: 3306, socket:/usr/local/mysql/data/mysqld.sock

Using server version 5.6.35-log

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /usr/local/mysql/data

xtrabackup: open files limit requested 65535,set to 1024000

xtrabackup: using the following InnoDBconfiguration:

xtrabackup:innodb_data_home_dir = .

xtrabackup:innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:innodb_log_group_home_dir = ./

xtrabackup:innodb_log_files_in_group = 2

xtrabackup:innodb_log_file_size = 536870912

InnoDB: Number of pools: 1

170427 17:28:03 >> log scanned up to(1796758)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 15 formysql/slave_master_info, old maximum was 0

170427 17:28:04 [01] Compressing ./ibdata1 to/data/backups/compressed/2017-04-27/ibdata1.qp

170427 17:28:04 [01]…done

…………

170427 17:28:05 [01] Compressing./inc2/t1.frm to /data/backups/compressed/2017-04-27/inc2/t1.frm.qp

170427 17:28:05 [01]…done

170427 17:28:05 Finished backing upnon-InnoDB tables and files

170427 17:28:05 [00] Compressingxtrabackup_binlog_info

170427 17:28:05 [00]…done

170427 17:28:05 Executing FLUSHNO_WRITE_TO_BINLOG ENGINE LOGS…

xtrabackup: The latest check point (forincremental): ‘1796758’

xtrabackup: Stopping log copying thread.

.170427 17:28:05 >> log scanned up to(1796758)

170427 17:28:05 Executing UNLOCK TABLES

170427 17:28:05 All tables unlocked

170427 17:28:05 Backup created in directory’/data/backups/compressed/2017-04-27/’

MySQL binlog position: filename’mysql-bin.000005′, position ‘1761’, GTID of the last change ‘0e9896a7-14f7-11e7-a0e6-000c2900551e:1-17’

170427 17:28:05 [00] Compressingbackup-my.cnf

170427 17:28:05 [00]…done

170427 17:28:05 [00] Compressingxtrabackup_info

170427 17:28:05 [00]…done

xtrabackup: Transaction log of lsn (1796758)to (1796758) was copied.

170427 17:28:05 completed OK!

备份完成后目录结构如下

[root@linux-node2 backups]# llcompressed/2017-04-27/

total 248

-rw-r—– 1 root root400 Apr 27 17:28 backup-my.cnf.qp

-rw-r—– 1 root root 223722 Apr 27 17:28ibdata1.qp

drwxr-x— 2 root root54 Apr 27 17:28 inc1

drwxr-x— 2 root root54 Apr 27 17:28 inc2

drwxr-x— 2 root root54 Apr 27 17:28 incrememtal1

drwxr-x— 2 root root54 Apr 27 17:28 incrememtal2

drwxr-x— 2 root root4096 Apr 27 17:28 mysql

drwxr-x— 2 root root4096 Apr 27 17:28 performance_schema

drwxr-x— 2 root root22 Apr 27 17:28 test

-rw-r—– 1 root root152 Apr 27 17:28 xtrabackup_binlog_info.qp

-rw-r—– 1 root root113 Apr 27 17:28 xtrabackup_checkpoints

-rw-r—– 1 root root560 Apr 27 17:28 xtrabackup_info.qp

-rw-r—– 1 root root381 Apr 27 17:28 xtrabackup_logfile.qp

[root@linux-node2 backups]#

2、恢复准备preparing（数据整理）

准备整理数据前需要先解压备份数据，使用—decompress选项，如果出现如下错误，请安装qpress，可以使用yum安装。

[root@linux-node2 backups]# xtrabackup–decompress –target-dir=/data/backups/compressed/2017-04-27/

xtrabackup version 2.4.7 based on MySQLserver 5.7.13 Linux (x86_64) (revision id: 6f7a799)

170427 17:34:54 [01] decompressing./xtrabackup_logfile.qp

sh: qpress: command not found

cat: write error: Broken pipe

Error: thread 0 failed.

[root@linux-node2 backups]# xtrabackup –decompress–target-dir=/data/backups/compressed/2017-04-27/

xtrabackup version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64)(revision id: 6f7a799)

170427 17:35:45 [01] decompressing ./xtrabackup_logfile.qp

170427 17:35:45 [01] decompressing ./ibdata1.qp

…………

170427 17:35:46 [01] decompressing ./xtrabackup_binlog_info.qp

170427 17:35:46 [01] decompressing ./backup-my.cnf.qp

170427 17:35:46 [01] decompressing ./xtrabackup_info.qp

170427 17:35:46 completed OK!

解压后再使用前面实例中的第4，5步操作，完成数据恢复。�r�?�6R