xtrabackup原理

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

参考：http://mysql.taobao.org/monthly/2016/03/07/

参考：https://www.cnblogs.com/ivictor/p/15547387.html

 

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

xbstream -x -C /rds/mysql < full_backup.xbstream

 

 

 

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

 

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

一、前言

Percona XtraBackup（简称PXB）是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，并且全部开源，真可谓是业界良心。我们 RDS MySQL 的物理备份就是基于这个工具做的。

项目的 blueprint 和 bug 讨论放在 Launchpad，代码之前也放在 Launchpad，现在已经迁移到 Github 啦，项目更新发布非常快，感兴趣的可以关注 :-)

本文会介绍下备份工具的工作原理，希望对大家有所帮助。

二、工具集

软件包安装完后一共有4个可执行文件，如下：

usr
├── bin
│   ├── innobackupex
│   ├── xbcrypt
│   ├── xbstream
│   └── xtrabackup

其中最主要的是 innobackupex 和 xtrabackup，前者是一个 perl 脚本，后者是 C/C++ 编译的二进制。

xtrabackup 是用来备份 InnoDB 表的，不能备份非 InnoDB 表，和 mysqld server 没有交互；innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，还会和 mysqld server 发送命令进行交互，如加读锁（FTWRL）、获取位点（SHOW SLAVE STATUS）等。简单来说，innobackupex 在 xtrabackup 之上做了一层封装。

一般情况下，我们是希望能备份 MyISAM 表的，虽然我们可能自己不用 MyISAM 表，但是 mysql 库下的系统表是 MyISAM 的，因此备份基本都通过 innobackupex 命令进行；另外一个原因是我们可能需要保存位点信息。

另外2个工具相对小众些，xbcrypt 是加解密用的；xbstream 类似于tar，是 Percona 自己实现的一种支持并发写的流文件格式。两都在备份和解压时都会用到（如果备份用了加密和并发）。

本文的介绍的主角是 innobackupex 和 xtrabackup。

三、原理

1.通信方式

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

• xtrabackup_suspended_1
• xtrabackup_suspended_2
• xtrabackup_log_copied

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

1. innobackupex 在启动 xtrabackup 进程后，会一直等 xtrabackup 备份完 InnoDB 文件，方式就是等待 xtrabackup_suspended_2 这个文件被创建出来；
2. xtrabackup 在备完 InnoDB 数据后，就在指定目录下创建出这个文件，然后等这个文件被 innobackupex 删除；
3. innobackupex 检测到文件 xtrabackup_suspended_2 被创建出来后，就继续往下走；
4. innobackupex 在备份完非 InnoDB 表后，删除 xtrabackup_suspended_2 这个文件，这样就通知 xtrabackup 可以继续了，然后等 xtrabackup_log_copied 被创建；
5. xtrabackup 检测到 xtrabackup_suspended_2 文件删除后，就可以继续往下了。

是不是感觉有点不可思议，通过文件是否存在来控制进程，这种方式非常的不靠谱，因为非常容易被外部干扰，比如文件被别人误删掉，或者2个正在跑的备份控制文件误放在同一个目录下，就等着备份乱掉吧，但是 Percona 就是这么干的。

之所以这么搞，估计主要是因为 perl 和 C 二进制2个进程，没有既好用又方便的通信方式，搞个协议啥的太麻烦了。但是官方也觉得这种方式不靠谱，11年就搞了个 blueprint 要用C重写 innobackupex，终于在2.3 版本实现了，innobackupex 功能全部集成到 xtrabackup 里面，只有一个 binary，另外为了使用上的兼容考虑，innobackupex 作为 xtrabackup 的一个软链。对于二次开发来说，2.3 摆脱了之前2个进程协作的负担，架构上明显要好于之前版本。考虑到 perl + C 这种架构的长期存在，大多数读者朋友也基本用的2.3之前版本，本文的介绍也是基于老的架构（2.2版本），但是原理和2.3是一样的，只是实现上的差别。

2.备份过程

整个备份过程如下图：

1. innobackupex 在启动后，会先 fork 一个进程，启动 xtrabackup进程，然后就等待 xtrabackup 备份完 ibd 数据文件；
2. xtrabackup 在备份 InnoDB 相关数据时，是有2种线程的，1种是 redo 拷贝线程，负责拷贝 redo 文件，1种是 ibd 拷贝线程，负责拷贝 ibd 文件；redo 拷贝线程只有一个，在 ibd 拷贝线程之前启动，在 ibd 线程结束后结束。xtrabackup 进程开始执行后，先启动 redo 拷贝线程，从最新的 checkpoint 点开始顺序拷贝 redo 日志；然后再启动 ibd 数据拷贝线程，在 xtrabackup 拷贝 ibd 过程中，innobackupex 进程一直处于等待状态（等待文件被创建）。
3. xtrabackup 拷贝完成idb后，通知 innobackupex（通过创建文件），同时自己进入等待（redo 线程仍然继续拷贝）;
4. innobackupex 收到 xtrabackup 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。
5. 当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 xtrabackup（通过删文件） ，同时自己进入等待（等待另一个文件被创建）；
6. xtrabackup 收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知 innobackupex redo log 拷贝完成（通过创建文件）；
7. innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；
8. 最后 innobackupex 和 xtrabackup 进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待 xtrabackup 子进程结束后退出。

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

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

3.增量备份

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

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

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

4.恢复过程

如果看恢复备份集的日志，会发现和 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来启动了。

 

 一、备份命令

本地备份：

本地备份：--parallel=4  --slave-info /home/work/dump

本地压缩备份：-parallel=4 --compress --slave-info /home/work/dump

xbstream方式支持--compress压缩，tar方式不支持，需要gzip等第三方压缩支持，通常情况下xbstream流压缩更快一些，第三方的压缩相对较慢。

本地流备份：--parallel=4 --compress --slave-info /home/work/dump

/tmp为流备份的临时目录，请预留一定的空间。

本地tar流：--parallel=4 --stream=tar  --slave-info  /tmp > /home/work/dump/stream.tar

本地xbstream流：--stream=xbstream --slave-info  /tmp > /home/work/dump/stream.xbs

本地tar流压缩：--parallel=4 --stream=tar  --slave-info  /tmp | gzip > /home/work/dump/stream_gz.tar.gz

本地xbstream流压缩：--stream=xbstream   --compress  --slave-info  /tmp > /home/work/dump/stream_compress.xbs

远程流备份：

--parallel=4 --stream=tar  --slave-info  /tmp |  ssh root@192.168.1.111  "cat  ->  /home/work/backup/remote_stream.tar"

压缩方式：--parallel=4 --stream=tar  --slave-info  /tmp |  ssh root@192.168.1.111  "gzip >  /home/work/backup/remote_stream.tar"

  xbstream流解压:

- x为解压，-C为解压后的文件目录，xbstream命令包含在 innobackupex安装包中

xbstream -x < /home/work/backup/my.xbs -C  /home//work/backup/restore

 compress压缩文件解压：

/home/backup/restore为压缩文件存放目录，解压后默认存储在压缩文件所在目录，解压后删除掉.qp结尾的文件。

innobackupex --decompress --parallel=4 /home/work/backup/restore

find /home/work/backup/restore -name "*.qp" -delete

恢复：

--use-memory=4G --apply-log  /home/work/backup/restore

--copy-back  /home/work/backup/restore

 

 

1、xbstream 流式边备份边传输

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

这里假设：需要将10.10.10.10机器上3306端口的mysql服务备份到10.10.10.11机器上保存着。

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

在需要被备份的机器10.10.10.10上执行，但需要等10.10.10.11上先执行nc：

[work@10.10.10.10 tmp]$ innobackupex --defaults-file=/home/work/mysql/etc/my.cnf   --stream=xbstream --user=backup --password=123456  --host=127.0.0.1  --port=3306 --slave-info  /tmp/ | nc  10.10.10.11  5200

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

在保存备份文件的机器10.10.10.11上先执行

[work@10.10.10.11 tmp]$ nc -l  5200 --recv-only |xbstream  -x  -C  /home/work/tmp/

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

备份完成后，在保存备份文件的机器10.10.10.11上执行，进行恢复操作。

[work@10.10.10.11 tmp]$ innobackupex --apply-log /home/work/tmp/

 

 

远程备份：

1，远程存储备份机器上执行：nc和xbstream 

shell> ulimit -n 1000000; nc -ld 24268 |xbstream -x -C /home/work/2021-09-06_10-16-16

 

2，目标mysql实例上执行备份并传输：innobackupex 和nc

shell> cd /home/work/tmp_3306/2021-09-06_10-16-19/; 

shell> innobackupex --defaults-file=/mysql_3306/etc/my.cnf --user=backup --password=123456 --host=127.0.0.1 --slave-info --ftwrl-wait-timeout=60 --ftwrl-wait-query-type=all --ibbackup=xtrabackup --stream=xbstream --tmpdir=/home/2021-09-06_10-16-19/ . 2> /home/work/xtra.log | nc 10.10.10.11 24268

 

3，恢复日志：

备份完成后，在保存备份文件的机器10.10.10.11上执行，进行恢复操作。
[work@10.10.10.11 tmp]$ innobackupex --apply-log  /home/work/2021-09-06_10-16-16

# 下面命令也可以：
shell> xtrabackup --defaults-file=/home/work/10.10.10.10_3306/2021-09-06_10-16-16/backup-my.cnf --use-memory=12147483648 --prepare --apply-log-only --target-dir=/home/work/10.10.10.10_3306/2021-09-06_10-16-16

 

 

 命令详解：

备份机：表示mysql实例所在的机器，这是需要被备份的机器

--defaults-file：必须放在innobackupex命令后作为第一个参数。

--stream=tar：表示tar格式流备份

--slave-info：表示在备份从库时,可以使用该参数，加上--slave-info备份目录下会多生成一个xtrabackup_slave_info 文件, 这里会保存主日志文件以及偏移, 文件内容类似于:CHANGE MASTER TO MASTER_LOG_FILE='', MASTER_LOG_POS=0。

/home/work/tmp：表示临时文件存放地方

|gzip  > full.tar.gz ：表示将innobackupex命令的输出通过管道作为gzip命令的输入，最后将其

 

 

 

5.7.25版本的mysql备份：

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

shell> innobackupex --defaults-file=/home/work/mysql_3306/etc/my.cnf   --stream=tar --user=mysqlbackup --password=123456 --host=127.0.0.1 --slave-info  /home/work/tmp |gzip  > full.tar.gz

解压：
shell> tar -xzvf   full.tar.gz   -C  ./tmp

# 进入解压目录执行：
shell> innobackupex  --apply-log   .

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

 

5.5.31的mysql版本备份：

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

shell> innobackupex --defaults-file=/home/work/mysql/etc/my.cnf    --user=mysqlbackup --password=123456 --host=127.0.0.1 --slave-info  ./

# 进入解压目录执行：
shell> innobackupex  --apply-log   .


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

 

边备份边传输：

新机器
nc -l  9999 --recv-only|xbstream  -x  -C .
# 结束完一定要apply log
innobackupex  --apply-log   .

备份机器
innobackupex --defaults-file=/home/work/mysql/etc/my.cnf   --stream=xbstream --user=mysqlbackup --password=123456 --host=127.0.0.1 --slave-info  /tmp/ | nc 新机器hostname  9999

 

 

二、5.5.31版本mysql的备份案例（81G的data）

开始备份：

shell> innobackupex --defaults-file=/home/work/mysql/etc/my.cnf    --user=mysqlbackup --password=123456 --host=127.0.0.1 --slave-info  ./ 

 

备份日志：

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

开始备份。

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

[work@igoodful tmp]$ innobackupex --defaults-file=/home/work/mysql/etc/my.cnf    --user=backup --password=123456 --host=127.0.0.1 --slave-info  ./      

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013.  All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

200618 09:51:27  innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_file=/home/work/mysql/etc/my.cnf;mysql_read_default_group=xtrabackup;host=127.0.0.1' as 'backup'  (using password: YES).
200618 09:51:27  innobackupex: Connected to MySQL server
200618 09:51:27  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!".

innobackupex:  Using server version 5.5.31-log

innobackupex: Created backup directory /home/work/tmp/2020-06-18_09-51-27

200618 09:51:27  innobackupex: Starting ibbackup with command: xtrabackup  --defaults-file="/home/work/mysql/etc/my.cnf"  --defaults-group="mysqld" --backup --suspend-at-end --target-dir=/home/work/tmp/2020-06-18_09-51-27 --tmpdir=/home/work/mysql/tmp --extra-lsndir='/home/work/mysql/tmp'
innobackupex: Waiting for ibbackup (pid=2130) to suspend
innobackupex: Suspend file '/home/work/tmp/2020-06-18_09-51-27/xtrabackup_suspended_2'

xtrabackup version 2.2.8 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /home/work/mysql/data
xtrabackup: open files limit requested 0, set to 150240
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 3
xtrabackup:   innodb_log_file_size = 268435456
xtrabackup: using O_DIRECT
>> log scanned up to (266620108746)
xtrabackup: Generating a list of tablespaces
[01] Copying ./ibdata1 to /home/work/tmp/2020-06-18_09-51-27/ibdata1
[01]        ...done
[01] Copying ./galaxy_availability/FDS_AVAILABILITY_MINUTE.ibd to /home/work/tmp/2020-06-18_09-51-27/galaxy_availability/FDS_AVAILABILITY_MINUTE.ibd
[01]        ...done
>> log scanned up to (266620108746)
[01] Copying ./galaxy_availability/EMR_FUSION_AVAILABILITY_MINUTE.ibd to /home/work/tmp/2020-06-18_09-51-27/galaxy_availability/EMR_FUSION_AVAILABILITY_MINUTE.ibd
[01]        ...done
[01] Copying ./galaxy_availability/FDS_FUSION_AVAILABILITY_DAY.ibd to /home/work/tmp/2020-06-18_09-51-27/galaxy_availability/FDS_FUSION_AVAILABILITY_DAY.ibd
[01]        ...done
[01] Copying ./galaxy_availability/SDS_FUSION_AVAILABILITY_DAY.ibd to /home/work/tmp/2020-06-18_09-51-27/galaxy_availability/SDS_FUSION_AVAILABILITY_DAY.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/auth_user.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/auth_user.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/apps.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/apps.ibd
>> log scanned up to (266620108746)
>> log scanned up to (266620108746)
>> log scanned up to (266620108746)
>> log scanned up to (266620428552)
>> log scanned up to (266620430368)
[01]        ...done
[01] Copying ./awsind_resource_management/appTrackingUrl.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/appTrackingUrl.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/bills.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/bills.ibd
>> log scanned up to (266620431271)
[01]        ...done
[01] Copying ./awsind_resource_management/cluster_availability.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/cluster_availability.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/containers.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/containers.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/operations.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/operations.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/bills_v2.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/bills_v2.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/xiaomi_teams.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/xiaomi_teams.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/auth_team.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/auth_team.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/__apps_old.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/__apps_old.ibd
>> log scanned up to (266620574530)
>> log scanned up to (266620574530)
>> log scanned up to (266620574530)
>> log scanned up to (266620577856)
..............
>> log scanned up to (266620579134)
>> log scanned up to (266620580930)
>> log scanned up to (266620582722)
>> log scanned up to (266620584094)
[01]        ...done
[01] Copying ./awsind_resource_management/containers_summary.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/containers_summary.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/clusters.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/clusters.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/queues.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/queues.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/cluster_state.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/cluster_state.ibd
>> log scanned up to (266620585450)
[01]        ...done
[01] Copying ./awsind_resource_management/bills_v3.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/bills_v3.ibd
>> log scanned up to (266620586840)
[01]        ...done
[01] Copying ./awsind_resource_management/schedules.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/schedules.ibd
[01]        ...done
[01] Copying ./awsind_resource_management/monitor.ibd to /home/work/tmp/2020-06-18_09-51-27/awsind_resource_management/monitor.ibd
>> log scanned up to (266620587297)
>> log scanned up to (266620587297)
>> log scanned up to (266620587297)
>> log scanned up to (266620587297)

xtrabackup: Creating suspend file '/home/work/tmp/2020-06-18_09-51-27/xtrabackup_suspended_2' with pid '2130'

200618 10:00:03  innobackupex: Continuing after ibbackup has suspended
200618 10:00:03  innobackupex: Executing FLUSH TABLES WITH READ LOCK...
200618 10:00:03  innobackupex: All tables locked and flushed to disk

200618 10:00:03  innobackupex: Starting to backup non-InnoDB tables and files
innobackupex: in subdirectories of '/home/work/mysql/data/'
innobackupex: Backing up files '/home/work/mysql/data//galaxy_availability/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (23 files)
innobackupex: Backing up files '/home/work/mysql/data//druid/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (11 files)
innobackupex: Backing up files '/home/work/mysql/data//awsind_resource_management/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (25 files)
>> log scanned up to (266622132062)
innobackupex: Backing up files '/home/work/mysql/data//owl2_azmb/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (32 files)
innobackupex: Backing up file '/home/work/mysql/data//dba_metadata/karma.frm'
innobackupex: Backing up file '/home/work/mysql/data//dba_metadata/cluster.frm'
innobackupex: Backing up file '/home/work/mysql/data//dba_metadata/db.opt'
innobackupex: Backing up files '/home/work/mysql/data//mysql/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (72 files)
innobackupex: Backing up file '/home/work/mysql/data//sparksql/grant_history.frm'
innobackupex: Backing up file '/home/work/mysql/data//sparksql/sparksql_queue_review.frm'
innobackupex: Backing up file '/home/work/mysql/data//sparksql/kudu_table_reviews.frm'
innobackupex: Backing up file '/home/work/mysql/data//sparksql/history.frm'
innobackupex: Backing up file '/home/work/mysql/data//sparksql/db.opt'
innobackupex: Backing up file '/home/work/mysql/data//sparksql/sparksql_queue.frm'
innobackupex: Backing up files '/home/work/mysql/data//performance_schema/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (18 files)
innobackupex: Backing up files '/home/work/mysql/data//hbase_manager/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (16 files)
200618 10:00:04  innobackupex: Finished backing up non-InnoDB tables and files

200618 10:00:04  innobackupex: Failed to get master binlog coordinates from SHOW SLAVE STATUS
200618 10:00:04  innobackupex: This means that the server is not a replication slave. Ignoring the --slave-info option
200618 10:00:04  innobackupex: Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
200618 10:00:04  innobackupex: Waiting for log copying to finish

xtrabackup: The latest check point (for incremental): '266622099673'
xtrabackup: Stopping log copying thread.
.>> log scanned up to (266622132062)

xtrabackup: Creating suspend file '/home/work/tmp/2020-06-18_09-51-27/xtrabackup_log_copied' with pid '2130'
xtrabackup: Transaction log of lsn (266620104647) to (266622132062) was copied.
200618 10:00:05  innobackupex: All tables unlocked

innobackupex: Backup created in directory '/home/work/tmp/2020-06-18_09-51-27'
innobackupex: MySQL binlog position: filename 'mysql-bin.000550', position 794971537
200618 10:00:05  innobackupex: Connection to database server closed
200618 10:00:05  innobackupex: completed OK!
###############################################################################################################

备份完毕。

###############################################################################################################
[work@igoodful tmp]$ ls
2020-06-18_09-51-27
[work@igoodful tmp]$ cd 2020-06-18_09-51-27/
[work@igoodful 2020-06-18_09-51-27]$ ls
awsind_resource_management  backup-my.cnf  dba_metadata  druid  galaxy_availability  hbase_manager  ibdata1  mysql  owl2_azmb  performance_schema  sparksql  xtrabackup_binlog_info  xtrabackup_checkpoints  xtrabackup_info  xtrabackup_logfile

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

在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。

因此，此时数据文件仍处理不一致状态。--apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。

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

 

应用log：

shell> innobackupex  --apply-log   .

日志如下：

[work@igoodful 2020-06-18_09-51-27]$ innobackupex  --apply-log   .

####################################################################################################################
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona LLC and/or its affiliates 2009-2013.  All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

200618 10:02:01  innobackupex: Starting the apply-log operation

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


200618 10:02:01  innobackupex: Starting ibbackup with command: xtrabackup  --defaults-file="/home/work/tmp/2020-06-18_09-51-27/backup-my.cnf"  --defaults-group="mysqld" --prepare --target-dir=/home/work/tmp/2020-06-18_09-51-27

xtrabackup version 2.2.8 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
xtrabackup: cd to /home/work/tmp/2020-06-18_09-51-27
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2277376, start_lsn=(266620104647)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2277376
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2277376
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 266620104647
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages 
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 266622132062 (100%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 
                             71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 794971537, file name /home/work/mysql/log/mysql-bin.000550
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.22 started; log sequence number 266622132062

[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 794971537, file name /home/work/mysql/log/mysql-bin.000550

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 266622132466

200618 10:02:04  innobackupex: Restarting xtrabackup with command: xtrabackup  --defaults-file="/home/work/tmp/2020-06-18_09-51-27/backup-my.cnf"  --defaults-group="mysqld" --prepare --target-dir=/home/work/tmp/2020-06-18_09-51-27
for creating ib_logfile*

xtrabackup version 2.2.8 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
xtrabackup: cd to /home/work/tmp/2020-06-18_09-51-27
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 3
xtrabackup:   innodb_log_file_size = 268435456
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 3
xtrabackup:   innodb_log_file_size = 268435456
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Setting log file ./ib_logfile101 size to 256 MB
InnoDB: Progress in MB: 100 200
InnoDB: Setting log file ./ib_logfile1 size to 256 MB
InnoDB: Progress in MB: 100 200
InnoDB: Setting log file ./ib_logfile2 size to 256 MB
InnoDB: Progress in MB: 100 200
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=266622132466
InnoDB: Highest supported file format is Barracuda.
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.22 started; log sequence number 266622132748

[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 794971537, file name /home/work/mysql/log/mysql-bin.000550

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 266622133278
200618 10:02:09  innobackupex: completed OK!

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

日志应用完毕，此时的备份就可以完全用于恢复了。

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

[work@igoodful 2020-06-18_09-51-27]$ 

 

 

 

 

三、5.7.25的mysql备份

备份均需要的参数：--defaults-file=/home/work/mysql_3306/my.cnf  --host=xxx --port=3306 --user=root --password=root

全量备份：--parallel=4  --extra-lsndir=lsn_dir --no-timestamp  --slave-info   /home/work/full

增量备份1：--no-timestamp --extra-lsndir=lsn_dir --incremental-basedir=/home/work/full --incremental /home/work/incre_first

增量备份2：--no-timestamp --extra-lsndir=lsn_dir  --incremental-basedir=/home/work/incre_first --incremental /home/work/incre_second

增量备份3：--extra-lsndir=lsn_dir --no-timestamp--incremental-basedir=/home/work/incre_second --incremental /home/work/incre_third

增量恢复：

--use-memory=4G --apply-log --redo-only  /home/work/full

--use-memory=4G --apply-log --redo-only  /home/work/full --incremental-dir=/home/work/incre_first

--use-memory=4G --apply-log --redo-only  /home/work/full --incremental-dir=/home/work/incre_second

--use-memory=4G --apply-log                    /home/work/full  --incremental-dir=/home/work/incre_third

停止恢复机上运行的实例：mysql.server stop

拷贝前请清空数据文件，拷贝数据文件：rm -rf /data/mysql_3306/data/*

替换data目录：innobackupex  --copy-back /home/backup/full

查看恢复的binlog位置：

cat  /home/work/full/xtrabackup_binlog_info
或者cat /data/work/data/xtrabackup_binlog_pos_innodb

启动实例：

mysql.server start

与开发业务确认好应用的binlog位置，应用binlog：多个binlog文件时，start-position或stop-position都仅对第一个binlog文件有效（如果未开户gtid，可以不添加--skip-gtids ）

mysqlbinlog --start-position=1580  /data/mysql/log/mysql_bin.000057    /data/mysql/log/mysql_bin.000058     | mysql

如果是多个binlog文件需要指定位置，建议使用以下方法经·：

mysqlbinlog --start-position=1111 --stop-position=2222 --skip-gtids /data/work/log/mysql_bin.000055 >  /home/mysql/dump.sql  

mysqlbinlog --start-position=111  --stop-position=555 --skip-gtids /data/work/log/mysql_bin.000066 >> /home/mysql/dump.sql 

 mysql -e "source /home/work/dump.sql ;"

 不建议使用如下方式（可能会因为session的不同，而造成临时表的操作失败）：

mysqlbinlog --start-position=1580 --stop-position=2202 --skip-gtids /data/mysql/log/mysql_bin.000057 | mysql

mysqlbinlog --start-position=154  --stop-position=467 --skip-gtids /data/mysql/log/mysql_bin.000058 | mysql

远程备份：

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

 # innobackupex  --defaults-file=/home/work/mysql_3306/conf/my.cnf --user=root --password=root --port=3306 --parallel=4 --extra-lsndir=/data/backup/lsndir  --stream=xbstream --compress --compress-threads=4  --slave-info   /data/tmp | ssh mysql@10.10.10.10  "xbstream -x -C  /data/backup/2022"

# 上传qpress-11-linux-x64.tar

# tar -xf qpress-11-linux-x64.tar  -C /usr/sbin

# chmod  +x  /usr/sbin/qpress   
# innobackupex --decompress --parallel=4  /data/backup/2022
 # find /data/backup/2022 -name "*.qp" -delete 

#xtrabackup --prepare --target-dir= /data/backup/2022

innobackupex --apply-log /data/backup/2022

mv /data/backup/2022/*  /data/mysql/data

chown work:work-R /data/mysql/data/

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

# innobackupex --defaults-file=/home/work/mysql_3306/conf/my.cnf --user=root --password=root --port=3306 --socket=/home/work/mysql_3306/tmp/mysql.sock --parallel=8 --slave-info --stream=xbstream --extra-lsndir=/tmp/chkpoint /tmp | sshpass -p 'password' ssh user@ip " xbstream -x -C /home/work/data/xtrabackup/"

 

重要参数说明:

--parallel          开启多个子进程并发备份多个数据文件,一个进程备份一个文件，在服务器性能不足时，谨慎使用。

--compres       压缩备份，传输到目标服务器的时候需要先解压再恢复，但解压前需要先下载qpress，将可执行文件放于/usr/local，恢复前需先执行innobackupex --decompress 目录 解压。

--stream          指定流式备份的格式，可指定tar或xbstream

--slave-info      在备份从库时,可以使用该参数，在备份目录下会多生成一个xtrabackup_slave_info 文件, 这里会保存主binlog日志文件以及偏移, 文件内容类似于:CHANGE MASTER TO MASTER_LOG_FILE='',
                        MASTER_LOG_POS=0。这个参数适用的场景：假设现在有主库A和从库B，目前想再添加一台备库C，并让备库C以主库A为master；因为主库A是生产库，压力一般比较大，
                        所以我们就在备库B上备份一个数据库，然后把这个备份拿到C服务器上 并导入到C库，接下来再在C服务器上执行change master的命令：
                        其中 master_host是A的ip,而master_log_file和master_log_pos就是这个xtrabackup_slave_info里面的值。

--extra-lsndir   指定xtrabackup_checkpoints文件的保留目录

sshpass          源端和目标端没有配置互信的情况下，需要安装sshpass,如已配置则不需要此参数。

 

恢复：

1.在需要恢复的机器停掉 

2.删除data文件 rm -fr /home/work/mysql_3306/data/*                            #日志文件不在此目录下

3.恢复 innobackupex /home/work/mysql_3306/conf/my.cnf  --apply-log  /home/work/data/xtrabackup
          innobackupex /home/work/mysql_3306/conf/my.cnf --copy-back /home/work/data/xtrabackup

流式备份的前提：源端和目标端均要安装xtrabackup：

 

 

 

 

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