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

** 实战演练:利用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文件

1
2
3
4
5
6
7
[xtrabackup]
host localhost
port 3306
user root
password 123456
socket /var/lib/mysql/mysql.sock

2.3.授予root用户BACKUP_ADMIN权限

1
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工具

1
yum install qpress -y

3. 压缩备份

登陆数据库创建employees2 表,为后面测试做准备

1
2
3
4
5
6
7
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.创建压缩备份

1
xtrabackup --backup --compress --target-dir /data/compressed/

3.2.创建全量备份

1
xtrabackup --backup --target-dir /data/backup_compressed/

3.3.对比两个备份的大小

可以看到压缩的备份比没有压缩的备份要小很多

4.解压备份

1
xtrabackup --decompress --target-dir /data/compressed/

5.准备备份

1
xtrabackup --prepare --target-dir /data/compressed/

6.备份恢复

登陆数据库 删除之前创建的表

停止MySQL服务进行恢复数据

1
2
systemctl stop mysqld
rsync -avrP /data/full_backup/ /var/lib/mysql/

恢复数据时,一定要记得更改数据目录下的文件拥有者以及所属组权限,否则mysql无法启动

1
2
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 用户家目录下的配置文件 等。 】。