MySQL5.7基于mysqldump、xtrbackup、innobackupex工具进行全量备份/恢复、增量备份/恢复

---

mysql全量备份脚本

---

前言

在实际生产环境中,数据库备份与恢复是数据库管理中最重要的方面之一。如果数据库崩溃却没有办法恢复，那么对企业造成的毁灭性结果可能会是数据丢失、收入减少、客户不满等。不管公司是使用单个数据库还是多个数据库来存储数百 GB 或 TB 的数据，它们都有一个共同点，即需要制订一个备份与恢复方案来备份重要数据并使自身免于灾难。切记没有备份的数据库非常危险！磁盘故障、数据误操作、删除后无法还原，例如drop，truncate后无法进行数据恢复。因此本篇文章主要记录了实际生产环境中数据库基于完全备份的恢复操作及恢复操作的相关知识。

---

一、数据库备份分类

数据库备份技术分类	优点	缺点
逻辑备份	可移植性强。恢复时，对平台、操作系统、MySQL 版本无要求；使用灵活，可备份恢复单库单表，结构等；备份文件较小。可远程发起备份；恢复后，能有效收缩空间	备份、恢复速度慢。尤其是恢复速度，相当于批量执行 SQL 备份过大时恢复会很慢；备份可能会 “污染” 缓冲池。操作过程中会锁表
物理备份	备份和恢复速度快，配置完成后直接基于备份启动数据库即可;无需实例在线，实例在关闭的情况下，也可以拷贝物理文件 ;操作过程中不会锁表	备份文件大;恢复时，对平台、操作系统、MySQL 版本和参数，必需一致或兼容;只能在本地发起备份。因为是直接拷贝数据文件，表空间中的 “空间碎片” 无法通过备份恢复收缩

逻辑备份包含使用mysqldump命令导出并存储在二进制文件/SQL文件中的数据,只能还原至备份的时间点
操作过程中会锁表

物理备份是物理数据库文件的副本,可以利用全备份+增量binlog备份恢复至任意时间点,例如使用xtrbackup备份工具
操作过程中不会锁表

数据库备份方式分类	特点
完全备份	对整个数据库的备份、数据库结构和文件结构的备份。需要花费更多的时间和空间
增量备份	因每次仅备份自上一次备份（注意是上一次，不是第一次）以来有变化的文件，所 以备份体积小，备份速度快，但是恢复的时候，需要按备份时间顺序，逐个备份版本进行恢复，恢复时间长。
差异备份	占用空间比增量备份大，比完整备份小，恢复时仅需要恢复第一个完整版本和最后 一次的差异版本(包含所有的差异)，恢复速度介于完整备份和增量备份之间。

二、为什么需要备份？

用以下三个例子说明备份的重要性

有一个生产库的用户下面的表不见了，怀疑人为被删除了，现在需要马上恢复下？

研发提交执行sql语句不小心where条件写错了，导致表中该字段所有记录被更新了，现在需要还原该字段？

检查发现从库同步失败，需要重建从库，但主库业务级别7*24，并且数据量比较大（600GB左右），如何搭建从库？

通过以上三个例子,足以说明备份的重要性,何况,每个项目终验或等保阶段,必须是要有数据库备份的,如果没有,则很难通过。更重要的是备份的作用是为了保证数据的一致性、服务的可用性

三、备份工具示例

1.逻辑备份工具

1.1.使用场景

1、研发确认周四晚19:00业务进行上线操作,则会通知运维/DBA在上线前针对某个库/某个表进行数据备份,确保数据的一致性和准确性

2、研发或客户需要某个表中的全部数据

结合以上场景,则使用逻辑备份工具mysqldump即可

1.2.备份操作示例

mysqldump备份单库

[root@mysql1 ~]# dbname=test  #指定数据库名
[root@mysql1 ~]# port=3308   #指定数据库端口
[root@mysql1 ~]# /data/mysql-5.7.42/bin/mysqldump  -uroot -S /data/my${port}/run/mysqld.sock -p  
--default-character-set=utf8 --opt  --hex-blob  --skip-tz-utc  --add-drop-database=FALSE  
--add-drop-table=FALSE --single-transaction  --set-gtid-purged=OFF   
--log-error=${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.err  ${dbname}   > 
${dbname}.full.sql.`date +%Y%m%d_%H%M%S` 2>${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.log

mysqldump备份多个库

[root@mysql1 ~]# port=3308   #指定数据库端口
[root@mysql1 ~]# /data/mysql-5.7.42/bin/mysqldump  -uroot -S /data/my${port}/run/mysqld.sock -p  
--default-character-set=utf8 --opt  --hex-blob  --skip-tz-utc  --add-drop-database=FALSE  
--add-drop-table=FALSE --single-transaction  --set-gtid-purged=OFF   
--log-error=${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.err  --databases xx1 xx2  > 
${dbname}.full.sql.`date +%Y%m%d_%H%M%S` 2>${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.log

mysqldump备份整个库

[root@mysql1 ~]# port=3308   #指定数据库端口
[root@mysql1 ~]# /data/mysql-5.7.42/bin/mysqldump  -uroot -S /data/my${port}/run/mysqld.sock -p  
--default-character-set=utf8 --opt  --hex-blob  --skip-tz-utc  --add-drop-database=FALSE  
--add-drop-table=FALSE --single-transaction  --set-gtid-purged=OFF   
--log-error=${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.err  --all-databases  > 
${dbname}.full.sql.`date +%Y%m%d_%H%M%S` 2>${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.log

mysqldump备份单表

[root@mysql1 ~]# dbname=test 库名
[root@mysql1 ~]# port=3308   #指定数据库端口
[root@mysql1 ~]# /data/mysql-5.7.42/bin/mysqldump  -uroot -S  /data/my3306/run/mysqld.sock -p  
--default-character-set=utf8   --opt  --hex-blob  --skip-tz-utc  --add-drop-database=FALSE  
--add-drop-table=FALSE --single-transaction  --set-gtid-purged=OFF   
--log-error=${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.err  ${dbname} --tables  <要备份的表名> 
> ${dbname}.full.sql.`date +%Y%m%d_%H%M%S` 2>${dbname}.full.sql.`date +%Y%m%d_%H%M%S`.log

mysqldump参数解释

参数	含义
–default-character-set=utf8	指定备份的字符集为utf8
–opt	启用一组优化选项，包括 --quick、–add-drop-table、–add-locks、–create-options、–disable-keys 和 --extended-insert。这是一个常用的选项组合，用于提高备份速度并确保备份数据的一致性
–hex-blob	以十六进制格式备份 BLOB 类型的字段。适用于二进制数据，以避免数据丢失或损坏
–skip-tz-utc	备份时不会在备份文件的最前几行添加SET TIME_ZONE=‘+00:00’
–add-drop-database=FALSE	不在备份中添加 DROP DATABASE 语句。如果数据库已经存在，备份将不会包含删除现有数据库的语句。
–add-drop-table=FALSE	不在备份中添加 DROP TABLE 语句。备份将不会包含删除现有表的语句。
–single-transaction	在一个事务中进行备份，这样可以在备份期间保持数据一致性。适用于使用事务的存储引擎（例如 InnoDB）
–set-gtid-purged=OFF	开启了GTID功能的数据库,备份时需要添加该参数 。不设置 GTID（全局事务标识）的被清除信息。适用于某些情况下需要禁用 GTID 记录。
-R	备份存储过程时添加该参数(必须使用超管用户备份)
> ${dbname}.full.sql.date +%Y%m%d_%H%M%S	将标准输出重定向到一个以数据库名和时间戳命名的 SQL 文件。这个文件将包含备份的数据。
2>${dbname}.full.sql.date +%Y%m%d_%H%M%S.log	将标准错误输出重定向到一个以数据库名和时间戳命名的日志文件。这个文件将包含备份过程中的错误信息

1.3.恢复操作示例

mysql > source /tmp/xxxxx.full.sql  #将备份文件的后缀时间去掉,然后执行source命令进行恢复

2.物理备份工具

2.1.xtrbackup介绍

Xtrabackup 是由 Percona 公司开源的一款 MySQL 物理热备份工具，它能对InnoDB和XtraDB存储引擎的数据库非阻塞地备份。
它不暂停服务创建Innodb热备份;为mysql做增量备份；
在mysql服务器之间做在线表迁移；
使创建replication更加容易；
备份mysql而不增加服务器的负载。 

Percona Xtrabackup是一款针对MySQL数据库的开源、免费的热备工具，
支持增量备份，压缩备份和流备份等，功能十分强大，有以下优点:
1.备份速度快，且可靠
2.备份过程中不会打断正在执行的事务
3.能够基于压缩等功能节约磁盘空间和流量
4.自动备份校验
5.备份还原的速度更快
6.可以使用流备，将备份传输到另一台机器

2.2.使用场景

1、针对数据量不大的库做每天完全备份操作
2、当主从复制不一致出现问题时,需要重新恢复主从时需要备份

2.3.安装percona-xtrabackup

yum在线安装

[root@mysql1 ~]# yum -y install percona-xtrabackup-24.x86_64

离线安装,在通互联网的机器上通过downloadonly 提前下载好对应的rpm包,然后上传到mysql服务器上进行安装

[root@mysql1 ~]# yum -y install percona-xtrabackup-24.x86_64 --downloadonly --downloaddir=/tmp/
[root@mysql1 ~]# rz
[root@mysql1 ~]# yum -y localinstall ./*.rpm

工具检查

[root@mysql1 ~]# rpm -ql percona-xtrabackup-24 

2.4.xtrbackup备份原理

备份开始的时候:
1、首先会启动一个xtrabackup_log后台检测的进程，实时检测mysql redo的变化，一旦发现redo有新的日志写入，
立刻将日志写入到日志文件xtrabackup_log中

2、复制innodb的数据文件和系统表空间文件idbdata1到对应的以默认时间戳为备份目录的地方

3、复制结束后，执行flush table with read lock操作

4、复制.frm .myd .myi文件

5、并且在这一时刻获得binary log 的位置

6、将表进行解锁unlock tables

7、停止xtrabackup_log进程

2.5.percona-xtrabackup两种命令的区别

xtrbackup

只能备份innodb、xtrdb两种数据引擎的数据表,不能备份MyISAM数据引擎的表
xtrabackup命令只备份数据文件,并不备份数据表结构(.frm)
所以使用xtrabackup恢复的时候必须有对应表结构文件(.frm)

Xtrabackup 备份恢复有三个阶段，
第一阶段是备份阶段，将物理文件拷贝到备份目录。
第二阶段是 Prepare 阶段，应用 redo log 将数据文件恢复到备份结束时的一致性状态。
第三阶段是恢复阶段，就是将备份文件拷贝到 MySQL 数据目录下面，除了使用 Xtrabackup 命令拷贝，我们也可以手动拷贝。

2.5.1.全量本地备份命令示例

[root@mysql1 ~]#  /usr/bin/xtrbackup --defaults-file=/etc/mysql/my.cnf --user=root  
--password="$PASSWORD"  --backup  --lock-ddl-per-table --slave-info  --parallel=5 --socket=$MYSOCK 
--target-dir=$TARBACKUPDIR/$BACKUP_DATE > $TMPFILE 2>&1

Xtrabackup 备份成功后，日志最后一行会输出 completed OK!如下图所示

参数	含义
–backup	发起全量备份
-u,-p,-P,–socket	连接 mysql 实例，用户名、主机 IP、端口、密码
–slave-info	记录 slave 复制位点信息，一般备份从库需要指定该参数
–target-dir	备份文件的存放路径
–parallel	并发拷贝的线程数

备份出来的文件中，除了数据文件，还有以下额外的文件:

backup-my.cnf：该文件不是 MySQL 参数文件的备份，只是记录了一些 Innodb 引擎的参数，会在 Prepare 阶段用到。
xtrabackup_logfile：该文件用来保存拷贝的 redo log。
xtrabackup_binlog_info：binlog 位点信息和 GTID 信息。使用该备份恢复后，需要从该 binlog 位点进行增量恢复。
xtrabackup_slave_info：如果是对从库进行备份，指定 --slave-info 该文件会记录主节点的位点信息，取自 SHOW SLAVE STATUS 中的 Relay_Master_Log_File 和 Exec_Master_Log_Pos。如果是给主库备份，该文件为空。
xtrabackup_checkpoints：该文件记录了备份类型和 LSN 信息。
xtrabackup_info：该文件中，记录备份的详细信息。
xtrabackup_tablespaces：记录备份集中表空间的信息。

2.5.2.本地压缩备份命令示例

压缩备份通过 --compress 指定压缩算法

[root@mysql1 ~]# xtrabackup --backup --slave-info -u root -H 127.0.0.1 -P3306 -p'YouPassword' --compress --parallel=5 --target-dir=/data/backup/bakup_`date +"%F_%H_%M_%S"`

注意事项: 在 Prepare 阶段之前，必须要先进行解压，命令如下

[root@mysql1 ~]# xtrabackup --decompress --parallel=5 --target-dir=/data/backup/bakup_2023-11-13_14_44_55/

在解压过程中，需要注意的地方:
	解压过程中，同样可以指定 --parallel 参数，进行并行解压。
	解压后，默认不会删除压缩文件。如果需要删除，可以指定 --remove-original 参数。
	即便压缩文件没有被删除，当使用 --copy-back 将备份拷贝到数据目录时，默认也不会拷贝这些压缩文件。

2.5.3.全量流式备份

流式备份指将备份数据通过流的方式输出到 STDOUT，而不是备份文件中。结合管道，可将多个功能组合在一起，如压缩、加密、流控等。

注意事项:
	在 xtrabackup 2.4 版中支持 tar 和 xbstream 流格式，但 tar 格式不支持并行备份。
	在 xtrabackup 8.0 中，仅支持 xbstream 流格式，不再支持 tar 格式。

2.5.3.1.备份到远程主机

使用下方命令通过管道组合，实现本地不落盘，将备份保存到远程主机

[root@mysql1 ~]# xtrabackup --backup --slave-info  -u root -H 127.0.0.1 -P3306 -p'YouPassword' \
 --stream=xbstream --target-dir=/data/backup/bakup_`date +"%F_%H_%M_%S"` \
 2>/data/backup/xtrabackup.log   \
 | ssh root@172.16.104.7 "cat -  > /data/backup/backup.xbstream"

远程恢复的时候，需要先使用 xbstream 命令进行解压

[root@mysql1 ~]# xbstream -x --parallel=10 -C /data/backup/20231113 < ./backup.xbstream
 -x 表示解压
 --parallel 表示并行度
 -C 指定解压的目录，最后一级目录必须存在。

2.5.3.2.gzip 本地压缩备份

使用流式备份，配合管道使用 gzip 命令对备份在本地进行压缩。

[root@mysql1 ~]# xtrabackup --backup --slave-info  -u root -H 127.0.0.1 -P3306 -p'YouPassword' \
 --stream=xbstream --target-dir=/data/backup/bakup_`date +"%F_%H_%M_%S"` \
 | gzip - > /data/backup/backup1.gz

恢复时需要先使用 gunzip 解压，再使用 xbstream 解压，才能进行 Prepare 阶段

# gzip 解压
[root@mysql1 ~]# gunzip backup1.gz

# xbstream 解压
[root@mysql1 ~]# xbstream -x --parallel=10 -C /data/backup/backup_full < ./backup1

2.5.3.3.gzip 远程压缩备份

使用流式备份，配合管道将备份 ssh 到远程进行压缩。

[root@mysql1 ~]# xtrabackup --backup --slave-info  -u root -H 127.0.0.1 -P3306 -p'YouPassword' \
 --stream=xbstream --target-dir=/data/backup/bakup_`date +"%F_%H_%M_%S"` \
 | ssh root@192.168.56.131 "gzip - > /data/backup/backup1.gz"

恢复解压时的步骤与 2.5.3.2中的步骤 相同。

2.5.4.全量备份恢复数据

前面 介绍的都是xtrbackup工具全量备份阶段，接下来介绍如何恢复全量备份
恢复实例的数据目录必须为空，所以在恢复前，需要清空 MySQL 数据目录

注意事项:
	首先要进行 Prepare 阶段，在该阶段 Xtrabackup 会启动一个嵌入的 InnoDB 实例来进行 Crash Recovery。
	该实例的缓冲池的大小由 --use-memory 参数指定，默认为 100MB。
	如果有充足的内存，通过设置较大的 memory 可以减少 Prepare 阶段花费的时间。

具体操作流程

# 进入到备份目录执行该命令
[root@mysql1 ~]# xtrabackup --prepare --use-memory=2G --target-dir=./
Prepare 阶段执行完成后，备份目录下才会生成 redo log 文件，可据此判断备份文件是否执行过 Prepare 阶段。

以下方式二选一即可

Prepare 阶段完成后，下面进入恢复阶段，可以手动拷贝文件的方式到数据目录
[root@mysql1 ~]# xtrabackup --defaults-file=/etc/my.cnf --copy-back --parallel=10 --target-dir=./

Prepare 阶段完成后，下面进入恢复阶段，以移动文件的方式到数据目录
[root@mysql1 ~]# xtrabackup --defaults-file=/data/my3307/my.cnf --move-back --target-dir=./

	命令中 --copy-back 表示将备份数据文件拷贝到 MySQL 数据目录下。
	如果在存储空间不足的情况下，可以使用 --move-back 表示移动备份文件。
	数据文件拷贝到目标目录后，需要修改文件属组。
	chown -R mysql:myinstall /data/my3308/

至此,xtrbackup工具的全量备份与恢复就演示完成

innobackupex

innobackupex命令相当于冷备份，复制数据目录的索引，数据，结构文件，但会有短暂的锁表（时间依赖于MyISAM大小）。

innobackupex参考InnoDB Hotbackup的innoback脚本修改而来
innobackupex是perl脚本封装.主要为了可以同时备份InnoDB和MyISAM引擎的表，
但在处理MyISAM时需要加一个读锁，且加入可选项，如slave-info可记录备份恢复后作为slave需要的一些信息，
根据这些信息可以很方便的利用备份来重做slave

2.5.5.innobackupex命令参数示例

--compress: 压缩innodb数据文件备份
--compress-threads: 并行压缩worker线程数量
--compress-chunk-size: 每个压缩线程worker buffer大小，单位字节，默认64K
--encrypt: 通过ENCRYPTION_ALGORITHM算法加密innodb数据文件备份，目前支持的算法有ASE128、AES192、AES256
--encrypt-threads: 并行加密worker线程数量
--encrypt-chunk-size: 每个加密线程worker buffer大小，单位字节，默认64K
--encrypt-key: 使用合适长度加密key，因为会记录到命令行，所以不推荐使用
--encryption-key-file: 文件必须是一个简单二进制或文本文件，加密key可通过openssl rand -base64 24命令行命令生成
--include: 使用正则表达式匹配表的名字[db.tb]，要求为其指定匹配要备份表的完整名称，即databasename.tablename
--user: 备份账号
--password: 备份密码
--port: 备份数据库的端口.
--host: 备份数据库的地址.
--databases: 接受的参数为数据名，如果要指定多个数据库，彼此间需要以空格隔开，如"xtra_test dba_test"，在指定某数据库时，也可以只指定其中的某张表，如"mydatabase.mytable".注意该选项对innodb引擎表无效，还是会备份所有innodb表.此外此选项也可以接受一个文件为参数，文件中每一行为一个要备份的对象
--tables-file: 指定含有表列表的文件，格式为database.table，该选项直接传给--tables-file
--socket: mysql.sock所在位置，以便备份进程登录mysql
--no-timestamp: 表示不要创建一个时间戳目录来存储备份，指定到自己想要的备份文件夹
--ibbackup: 指定使用具体xtrabackup二进制程序.IBBACKUP-BINARY是运行percona xtrabackup命令.这个选项适用于xtrbackup二进制不在你是搜索和工作目录，如果指定了该选项，innoabackupex自动决定用的二进制程序.
--slave-info: 对slave备份时使用，打印master名字和binlog pos，同样将这些信息以change master的命令写入xtrabackup_slave_info文件.可以通过基于此备份启动一个从库.
--safe-slave-backup: 为保证一致性复制状态，这个选项停止SQL线程并且等到show status中的slave_open_temp_tables为0的时候开始备份，如果没有打开临时表，bakcup会立刻开始，否则SQL线程启动或者关闭知道没有打开的临时表.如果slave_open_temp_tables在--safe-slave-backup-timeount（默认300秒）秒之后不为0，从库sql线程会在备份完成的时候重启.
--rsync: 通过rsync工具优化本地传输，当指定该选项时innobackupex使用rsync拷贝非Innodb文件而替换cp，当有很多DB和表时会快很多，不能与—stream同时使用.
--kill-long-queries-timeout: 从开始执行FLUSH TABLES WITH READ LOCK到kill掉阻塞它的这些查询之间等待的秒数.默认值为0，不会kill任何查询，使用该选项xtrabackup需要有Process和super权限.
--kill-long-query-type: 表示kill的类型，默认是all，可选select.
--ftwrl-wait-threshold: 表示检测到长查询，单位秒，表示长查询阈值.
--ftwrl-wait-query-type: 表示获得全局锁之前允许哪种查询完成，默认是ALL，可选update.
--galera-info: 表示生成包含创建备份时本地节点状态的xtrabackup_galera_info文件，该选项只适用于备份PXC.
--stream: 表示流式备份格式，backup完成之后以指定格式到STDOUT，目前只支持tar和xbstream.
--defaults-file: 指定从哪个文件读取MySQL配置，必须放在命令行的第一个选项位置.
--defaults-extra-file: 指定在标准defaults-file之前从哪个额外的文件读取MySQL配置，必须在命令行的第一个选项位置.一般用于存备份用户的用户名和密码的配置文件.
--defaults-group: 表示从配置文件读取的组，innobakcupex多个实例部署时使用.
--no-lock: 表示关闭FTWRL的表锁，只有在所有表都是Innodb表并且不关心backup的binlog pos点，如果有任何DDL语句正在执行或者非InnoDB正在更新时(包括mysql库下的表），都不应该使用该选项，后果是导致备份数据不一致，如果考虑备份因为获得锁失败，可以考虑--safe-slave-backup立刻停止复制线程.
--tmpdir: 表示指定--stream时，指定临时文件存在位置，在streaming和拷贝到远程server之前，事务日志首先存在临时文件里.在使用参数stream=tar备份时xtrabackup_logfile可能会临时放在/tmp目录下，如果备份时并发写入较大，xtrabackup_logfile可能会很大(5G+)，很可能会撑满/tmp目录，此时可通过参数--tmpdir指定目录解决该问题.
--history: 表示percona server 的备份历史记录在percona_schema.xtrabackup_history表.
--incremental: 表示创建一个增量备份，需要指定--incremental-basedir.
--incremental-basedir: 表示接受一个字符串参数指定含有full backup的目录为增量备份的base目录，与--incremental同时使用.
--incremental-dir: 表示增量备份的目录.
--incremental-force-scan: 表示创建一份增量备份时强制扫描所有增量备份中的数据页.
--incremental-lsn: 表示指定增量备份的LSN，与--incremental选项一起使用.
--incremental-history-name: 表示存储在PERCONA_SCHEMA.xtrabackup_history基于增量备份的历史记录名字.Percona Xtrabackup搜索历史表查找最近(innodb_to_lsn)成功备份并且将to_lsn值作为增量备份启动初始lsn.与innobackupex--incremental-history-uuid互斥，若没有检测到有效的lsn，xtrabackup会返回error.
--incremental-history-uuid: 表示存储在percona_schema.xtrabackup_history基于增量备份的特定历史记录的UUID.
--close-files: 表示关闭不再访问的文件句柄，当xtrabackup打开表空间通常并不关闭文件句柄，目的是正确的处理DDL操作.若表空间数量巨大，这是一种可以关闭不再访问的文件句柄的方法.使用该选项有风险，会有产生不一致备份的可能.
--compact: 表示创建一份没有辅助索引的紧凑备份.
--throttle: 该选项表示每秒IO操作的次数，只作用于bakcup阶段有效.apply-log和--copy-back不生效不要一起用
--parallel=4: 备份所用的线程数
--databases-exclude: 备份时排除指定的数据库

2.5.6.全量本地备份示例

备份至文件

[root@mysql1 ~]# /usr/bin/innobackupex --defaults-file=/data/my3306/my.cnf
--user=dbbackup --password=dbbackup --backup --lock-ddl-per-table --socket=/data/my3306/run/mysqld.sock --slave-info /export/backup

2.5.7.流式全量本地压缩备份示例

将全量备份压缩为一个tar包

[root@mysql1 ~]# /usr/bin/innobackupex --defaults-file=/data/my3306/my.cnf
--user=dbbackup --password=dbbackup --backup --lock-ddl-per-table --socket=/data/my3306/run/mysqld.sock --slave-info /export/backup \
--stream=tar | gzip - >  /export/backup/full_20240913.tar.gz

备份成功后，日志最后一行会输出 completed OK!如下图所示

全量备份完成后,会在备份目录下有一个xtrabackup_info文件
这个文件包含了binlog_pos、备份开始、结束时间等关键信息.
尤其是binlog_pos这个参数的值对基于GTID同步模式的主从复制恢复有很大的作用

2.5.8.全量备份恢复

如果是已建立主从复制关系的mysql重新做主从，则需要删除从库中的以下目录{binlog、data、iblog、ibdata}

2.5.8.1.准备恢复操作

所谓准备恢复，就是要为恢复做准备。就是说备份集没办法直接拿来用，因为这中间可能存在未提交或未回滚的事务，数据文件不一致，所以需要对备份集做预处理的准备过程。

[root@mysql2 ~]# tar xf full_20240913.tar.gz -C /export/backup
[root@mysql2 ~]# /usr/bin/innobackupex --defaults-file=/data/my3307/my.cnf --user=root --apply-log
/export/backup/full_20240913   #生成回滚日志

准备恢复命令执行完成后,会如下图所示有个comleted OK!字样

2.5.8.2.真正执行恢复操作

将备份文件拷贝到 实例的数据文件目录.有以下两种方法

#第一种拷贝的方式 (默认使用innobackex方式)
[root@mysql2 ~]# innobackupex --defaults-file=/data/my3307/my.cnf --copy-back /export/backup/full_20240913

#第二种移动的方式
[root@mysql2 ~]# xtrabackup --defaults-file=/data/my3307/my.cnf --move-back --target-dir=/export/backup/full_20240913

看见 completed OK! 说明 已经拷贝完毕了!

2.5.8.3.修改目录权限，重启数据库

[root@mysql2 ~]# cd /data/my3307/data
[root@mysql2 ~]# chown mysql.myinstall ./* -R
[root@mysql2 ~]# /etc/init.d/my3307.server start

至此,基于innobackupex方式全量备份和恢复也就演示完成了

2.5.8. 增量备份流程

增量备份示意图

增量备份特点:
	因每次仅备份自上一次备份（注意是上一次，不是第一次）以来有变化的文件，
	所以备份体积小，备份速度快，但是恢复的时候，需要按备份时间顺序，逐个备份版本进行恢复，恢复时间长。

备份示例

增量备份需要基于全备,首先第一天进行一次全备
[root@mysql2 ~]#  /usr/bin/innobackupex --defaults-file=/data/my3306/my.cnf
--user=dbbackup --password=dbbackup --backup --lock-ddl-per-table --socket=/data/my3306/run/mysqld.sock --slave-info /export/backup

第二天在第一天的基础上进行增量备份

示例:
	第一天创建了一个test库,并插入了10条数据
	第二天又创建了一个test1库，并插入了15条数据
	接着 开始第二天的增量备份

[root@mysql2 ~]# /usr/bin/innobackupex --defaults-file=/data/my3306/my.cnf \
--user=dbbackup --password=dbbackup --backup --lock-ddl-per-table \
--socket=/data/my3306/run/mysqld.sock \
--incremental /export/backup  \
--incremental-basedir /export/backup/2024-09-10_23-34-43

[root@mysql2 ~]# ll /export/backup/
2024-09-09_23-33-57  #第一天全量备份产生的备份文件目录
2024-09-10_23-34-43  #第二天增量备份基于第一天产生的备份文件目录

上面语句执行成功之后，会在–incremental执行的目录下创建一个时间戳子目录
（本例中为：/export/backup/2024-09-10_23-34-43），在该目录下存放着增量备份的所有文件

参数解释:
	--incremental-basedir指向全备目录
	--incremental指向增量备份的目录

在备份目录下，有一个文件xtrabackup_checkpoints记录着备份信息，全备的信息如下:
backup_type = full-backuped
from_lsn = 0
to_lsn = 563759005914
last_lsn = 563759005914
从上面可以看出，增量备份的from_lsn正好等于全备的to_lsn

2.5.9. 增量恢复流程

增量备份的恢复要比全量备份复杂很多，增量备份与全量备份有着一些不同，尤其要注意的是:
	1、需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。
	2、基于所有的备份将未提交的事务进行“回滚”。于是，操作就变成了不能回滚，因为有可能第一次备份时候没提交，在增量中已经成功提交

2.5.9.1.第一步–>回滚合并操作

增量备份恢复示例

第一步是在所有备份目录下重做已提交的日志（注意备份目录路径要跟全路径）
[root@mysql2 ~]# innobackupex --apply-log --redo-only /export/backup/2024-09-09_23-33-57 #将第一天的全量备份进行重放操作

[root@mysql2 ~]#  innobackupex --apply-log --redo-only /export/backup/2024-09-09_23-33-57
--incremental-dir=/export/backup/2024-09-10_23-34-43 #将第二天的增量备份进行重放操作

依次类推到最后一个增量备份的重放操作

[root@mysql2 ~]# innobackupex --apply-log /export/backup/2024-09-09_23-33-57 --incremental-dir==/export/backup/2024-09-11_23-34-43

最后一步的增量备份并没有--redo-only选项！还有，可以使用--use-memory提高性能。以上语句执行成功之后，最终数据在BASE-DIR（即全备目录）下

2.5.9.2.第二部–>把增量目录下的数据整合到全量备份目录下

[root@mysql2 ~]# innobackupex --apply-log /export/backup/2024-09-09_23-33-57

2.5.9.3.第三步–>清除数据目录,开始拷贝数据，数据目录重新授权

第一步完成之后，我们开始下面关键的第二步，即拷贝文件，进行全部还原！注意：必须先停止mysql数据库，然后清空数据库目录(这里是指/data/my3307/data)下的文件。

[root@mysql2 ~]# /etc/init.d/mysqld3307.server stop
[root@mysql2 ~]# rm -rf /data/my3307/data/{data,binlog,ibdata,iblog}
[root@mysql2 ~]# innobackupex --defaults-file=/data/my3307/my.cnf \
--user=dbbackup  --copy-back /export/backup/2024-09-09_23-33-57 #第一天的全量备份目录
[root@mysql2 ~]# chown -R mysql.myinstall /data/my3307/*

至此,基于innobackupex方式的增量恢复到此完成,然后重启数据库并验证数据的准确性、一致性等

*************** 当你发现自己的才华撑不起野心时，就请安静下来学习吧！***************

总结

以上就是我对mysql5.7备份知识相关的分享，没有太多备份底层的知识,都是实际环境中使用到的备份操作命令,针对提到的三种备份方式，还差一种差异备份没有演示，因为这个在我的实际维护环境中并没有使用到。也只在自己的测试环境中执行过差异备份的相关命令，对其不熟练，因此没有写进去。不过，整篇文章中的全量备份/恢复、差异备份/恢复已足够应对实际环境中的要求。加油!!!