目录
1.前言
2.准备工作
2.1.环境信息
2.2.配置/etc/my.cnf文件
2.3.授予root用户BACKUP_ADMIN权限
2.4.安装qpress
3. 压缩备份
3.1.创建压缩备份
3.2.创建全量备份
3.3.对比两个备份的大小
4.解压备份
5.准备备份
6.备份恢复
7.问题分析
8.总结
"实战演练：利用Percona XtraBackup执行MySQL压缩备份操作详解"
1.前言
在延续上篇【MySQL备份】Percona XtraBackup增量备份实战篇的探讨之后，本文将深度挖掘Percona XtraBackup的另一重要维度——压缩备份的实战技巧。继成功导航增量备份的复杂水域后，我们现在转向优化存储空间的策略，探讨如何高效利用压缩技术，确保您的MySQL备份既紧凑又实用。
通过本篇章节，我们将超越基础备份实践，引领您步入一个更为精细的操作层面，展示如何在不牺牲数据完整性的前提下，运用巧妙的压缩策略减少备份存储占用。您将学习如何无缝集成压缩工具与Percona XtraBackup流程，从备份创建直至恢复的每一步，最大化资源效率，为您的数据保护计划增添灵活性与经济性。
无论您面临的是日益增长的数据存储压力，还是对提升灾难恢复速度的迫切需求，本文都将提供宝贵的实战指导，帮助您在数据备份的征途上，以更精简的脚印，迈开更坚实的步伐。让我们一同探索，如何在保障业务连续性的基础上，实现备份存储的最优化，开启MySQL备份策略的新篇章
2.准备工作
2.1.环境信息
| 主机IP | 操作系统 | Mysql版本 | XtraBackup版本 |
|---|---|---|---|
| 172.17.0.2 | CentOS Stream release 9 | 8.0.37 | 8.0.35 |
2.2.配置/etc/my.cnf文件
[xtrabackup]
host=localhost
port=3306
user=root
password=123456
socket=/var/lib/mysql/mysql.sock
2.3.授予root用户BACKUP_ADMIN权限
grant BACKUP_ADMIN on *.* to 'root'@'%'LOCK INSTANCE FOR BACKUP 是MySQL 8.0引入的一种新的备份相关SQL语句，主要用于在进行数据库备份时，以一种更为细粒度和高效的方式控制对数据库实例的访问，以保证备份的一致性。这个命令的工作原理及特点如下：
目的：在执行备份操作时，此命令用于获取一个实例级别的锁，该锁允许在备份过程中继续执行DML（数据操作语言，如INSERT、UPDATE、DELETE）操作，同时防止那些可能导致数据快照不一致的DDL（数据定义语言，如CREATE、ALTER、DROP）操作和某些管理操作。这样可以在不影响数据库服务的情况下进行备份，特别适用于需要最小化服务中断的在线备份场景。
权限需求：执行LOCK INSTANCE FOR BACKUP语句需要用户具备BACKUP_ADMIN权限。这是一个专门为了备份相关的高级操作而设计的权限级别。
兼容性：此特性是在MySQL 8.0及以上版本中引入的，早于8.0的MySQL版本并不支持这一语句，因此在使用旧版本时，可能需要依赖其他机制（如FLUSH TABLES WITH READ LOCK）来确保备份的一致性。
解锁：执行备份后，需要使用UNLOCK INSTANCE语句来释放之前由LOCK INSTANCE FOR BACKUP获得的锁，从而恢复正常操作。
与传统备份命令的对比：相比于传统的备份方法，如使用FLUSH TABLES WITH READ LOCK，LOCK INSTANCE FOR BACKUP提供了更小的性能影响，因为它不会完全阻止写操作，只是限制了可能引起数据不一致的活动，更适合于高可用性和高性能要求的生产环境。
2.4.安装qpress
xtrabackup --compress使用qpress工具
yum install qpress -y3. 压缩备份
登陆数据库创建employees2 表，为后面测试做准备
CREATE TABLE employees2(id INT AUTO_INCREMENT, -- 自增的ID作为主键first_name VARCHAR(50) NOT NULL, -- 姓名，最大长度50，不能为空email VARCHAR(100) UNIQUE, -- 电子邮件，最大长度100，必须唯一hire_date DATE, -- 入职日期PRIMARY KEY (id) -- 指定id列为表的主键) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 使用InnoDB存储引擎，字符集为utf8mb4支持更多字符
3.1.创建压缩备份
xtrabackup --backup --compress --target-dir=/data/compressed/
3.2.创建全量备份
xtrabackup --backup --target-dir=/data/backup_compressed/
3.3.对比两个备份的大小
可以看到压缩的备份比没有压缩的备份要小很多
4.解压备份
xtrabackup --decompress --target-dir=/data/compressed/
5.准备备份
xtrabackup --prepare --target-dir=/data/compressed/
6.备份恢复
登陆数据库 删除之前创建的表
停止MySQL服务进行恢复数据
systemctl stop mysqld
rsync -avrP /data/full_backup/ /var/lib/mysql/
恢复数据时，一定要记得更改数据目录下的文件拥有者以及所属组权限，否则mysql无法启动
chown -R mysql.mysql /var/lib/mysql
重启数据库查看数据是否恢复，可以看到之前被删除的表居然没有恢复成功
7.问题分析
按道理来说上面的操作应该没有什么问题的，为什么会没有恢复成功呐？刚开始的时候以为是备份的问题，然后将之前对比创建的全量备份进行恢复，但是恢复之后还是没有之前删除的那个表，本来这里准备创建个表然后弄个截图糊弄过去的，但是创建的时候居然报错了
报错这个表是存在的，那为什么看不到呐？既然库中看不到就去看数据目录
查看数据目录的时候明显可以看到这个表是存在的，说明我们备份恢复成功了，但是在数据库中没有显示出来，这是为什么？
8.总结
可以看到这篇文章和之前的有一些区别，在使用xtrabackup命令的时候没有像前面一样在命令行中添加参数，这是因为我们将这些信息配置到了/etc/my.cnf文件【当您将相关参数（如MySQL的用户名称、密码、端口等）配置到/etc/my.cnf或相应的配置文件中时，Percona XtraBackup等MySQL备份工具在执行命令时就可以自动读取这些配置，因而无需在命令行中显式地添加这些参数。这是因为XtraBackup以及大多数MySQL客户端工具在启动时会按照特定的顺序查找并读取配置文件，包括但不限于/etc/my.cnf、~/.my.cnf（用户家目录下的配置文件）等。 】。
