【MySQL备份】Percona XtraBackup压缩备份实战篇

目录

 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 -y

3. 压缩备份

登陆数据库创建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（用户家目录下的配置文件）等。 】。