在这个数据为王的时代，备份做不好，年终奖怕是都要打水漂。
已经看过很多系统的数据备份是使用mysqldump方式进行的，也看到过出现的故障： 例如一个已经超过1T的MySQL数据库业，依旧使用逻辑备份，而且也不加single-transaction，虽然备份在凌晨开始进行，但是由于表比较大，且凌晨也有其他的定时统计任务运行，导致到上班时间备份依旧在运行，数据库负责很大，应用系统响应超时，此时业务部门直接堵在门口“问候”，领导直接站着身后盯着优化处理。
因此，对于数据量比较大的数据库还是采用Percona XtraBackup进行物理备份更佳。本文我们就探讨一下使用Percona XtraBackup进行MySQL8.4的备份（MySQL8.0之后，备份方式已经丰富了很多了，但是还是习惯用Percona XtraBackup来进行），并且附加了详细的原理流程图，也可以供大家参考，尤其准备年后金三银四面试的伙伴们，内容稍微有点长，建议收藏备用。
一、 Percona XtraBackup备份实操案例
1. 工具下载及部署
从percona官网进行下载，对应地址：https://www.percona.com/downloads， 下拉找到ercona XtraBackup，选择对应的版本，操作系统，然后按照自己操作系统的glibc版本选择对应的软件包下载即可。本次我选择的是MySQL8.4版本，如图
下载完成后上传至服务器，解压即可使用
tar -zxvf percona-xtrabackup-8.4.0-2-Linux-x86_64.glibc2.17.tar.gz# 添加软链接ln -s percona-xtrabackup-8.4.0-2-Linux-x86_64.glibc2.17 xtrabackup
完成后进行测试，查看是否有异常，如果出现如下情况，则代表可以正常使用
[root@vbox xtrabackup]# bin/xtrabackup --version2026-02-03T03:42:32.338476-05:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --datadir=/var/lib/mysqlbin/xtrabackup version 8.4.0-2 based on MySQL server 8.4.0 Linux (x86_64) (revision id: d4373834)
根据官方文档说明（Percona XtraBackup 8.4版本），可以创建如下备份账号，并根据需求进行授权：
-- 创建备份专用用户CREATE USER 'backup' IDENTIFIED BY 'Backup@2026';-- 授予核心备份权限GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup' ;-- 授予性能模式表查询权限GRANT SELECT ON performance_schema.log_status TO 'backup' ;GRANT SELECT ON performance_schema.keyring_component_status TO 'backup' ;GRANT SELECT ON performance_schema.replication_group_members TO 'backup' ;-- 授予备份历史记录功能权限（可选）GRANT CREATE, ALTER, INSERT, SELECT ON PERCONA_SCHEMA.xtrabackup_history TO 'backup' ;-- 授予单个表恢复权限（可选）GRANT CREATE TABLESPACE ON *.* TO 'backup' ;-- 授予复制环境相关权限（可选）GRANT REPLICATION_SLAVE_ADMIN ON *.* TO 'backup' ;-- 刷新权限FLUSH PRIVILEGES;
2.2 配置备份脚本
生产环境需要定时任务或者调用脚本的方式进行备份，因此，可以编写一个shell脚本进行备份，例如：
生成一个full_backup.sh文件，添加如下内容（按照实际内容进行修改）：
#! bin/bashIPADDRESS='192.168.56.102'PORT=3306BACKUP_USER='backup'BACKUP_PASSWORD='XXXXXXXX'BACKUP_DIR='/data/backup'BACKUP_DATE=$(date +%Y%m%d)BACKUP_FILE="$BACKUP_DIR/ALL_BACKUP-$PORT-$IPADDRESS-$BACKUP_DATE.tar.gz"mkdir -p ${BACKUP_DIR}/dbbackuprm -rf ${BACKUP_DIR}/dbbackup/*# 执行备份操作/usr/local/xtrabackup/bin/xtrabackup --defaults-file=/data/mysql/mysql3306/etc/my.cnf --host=${IPADDRESS} --port=${PORT} --backup --user=${BACKUP_USER} --password=${BACKUP_PASSWORD} --parallel=2 --compress --compress-threads=4 --tmpdir=/data/backup --target-dir=${BACKUP_DIR}/dbbackup >> data/backup/backup.log 2>&1# 检查备份是否成功if [ $? -eq 0 ]; then# 执行打包操作tar -czvf ${BACKUP_FILE} -C ${BACKUP_DIR}/dbbackup .echo "备份成功：$(date +%Y-%m-%d_%H:%M:%S)"rm -rf ${BACKUP_DIR}/dbbackup/*# 清除历史备份find $BACKUP_DIR -name "ALL_BACKUP-$PORT-*.tar.gz" -mtime +15 -exec rm -f {} \;elseecho "备份失败：$(date +%Y-%m-%d_%H:%M:%S)"rm -rf ${BACKUP_DIR}/dbbackup/*fi
执行脚本即可手动完成一次全量备份
sh full_backup.sh
完整的执行日志在backup.log中可以查看，里面记录了详细的过程。
二、 XtraBackup备份流程拆解
下面我们结合日志及官方文档的内容，拆解一下 XtraBackup的备份流程。
1. 初始化和环境检测（21:01:08）
2026-02-03T21:01:08.799283-05:00 0 [Note] recognized server arguments: --server-id=1186 --datadir=/data/mysql/mysql3306/data...2026-02-03T21:01:08.799640-05:00 0 [Note] recognized client arguments: --port=3306 --socket=/data/mysql/mysql3306/tmp/mysql.sock...
关键信息：
XtraBackup版本：8.4.0-2，基于MySQL 8.4.0
目标MySQL版本：8.4.7
数据目录：/data/mysql/mysql3306/data
备份目录：/data/backup/dbbackup
使用压缩（--compress）和并行处理（--parallel=2）
2. 连接和认证（21:01:08-21:01:09）
2026-02-03T21:01:08.915926-05:00 0 [Note] Connecting to MySQL server host: 192.168.56.102, user: backup, password: set, port: 33062026-02-03T21:01:09.079466-05:00 0 [Note] Using server version 8.4.7
流程解析：
成功连接到MySQL服务器（192.168.56.102:3306）
使用备份用户backup进行认证
检测到服务器版本为MySQL 8.4.7
3. 获取备份锁（21:01:09）
2026-02-03T21:01:09.139168-05:00 0 [Note] Executing LOCK INSTANCE FOR BACKUP ...
技术要点：
使用LOCK INSTANCE FOR BACKUP而非传统的FLUSH TABLES WITH READ LOCK
这是MySQL 8.0+的轻量级备份锁，大大减少锁表时间
仅锁定非InnoDB表，InnoDB表继续正常服务
4. InnoDB数据文件备份（21:01:09-21:01:12）
4.1 环境初始化
2026-02-03T21:01:09.150466-05:00 0 [Note] cd to data/mysql/mysql3306/data2026-02-03T21:01:09.164906-05:00 0 [Note] using the following InnoDB configuration:
配置信息：
数据文件：ibdata1:12M:autoextend
日志文件：2个，每个1GB，位于/data/mysql/mysql3306/logs
使用O_DIRECT方式（直接I/O，绕过操作系统缓存）
4.2 并行备份innodb表的数据文件传输
2026-02-03T21:01:10.958157-05:00 0 [Note] Starting 2 threads for parallel data files transfer2026-02-03T21:01:10.973093-05:00 2 [Note] Compressing ./ibdata1 to data/backup/dbbackup/ibdata1.zst
备份的文件包括：
系统表空间：ibdata1
用户表空间：testdb/t7.ibd、testdb/t1.ibd、db_monitor/db_instances.ibd等
Undo表空间：undo_001、undo_002
系统表：mysql.ibd、sys/sys_config.ibd
技术特点：
使用2个并行线程进行数据传输
实时压缩（ZSTD格式），每个文件压缩完成后立即记录
保持LSN（Log Sequence Number）一致性
5. 备份非InnoDB表备份（21:01:13）
2026-02-03T21:01:12.994963-05:00 0 [Note] Starting to backup non-InnoDB tables and files
备份的非InnoDB文件类型：
CSV表：mysql/general_log.CSV、mysql/slow_log.CSV
SDI文件（Serialized Dictionary Information）：各种系统表的元数据文件
CSM文件：元数据文件
备份模式：
使用多个线程（线程4、5）并行压缩
每个文件独立处理，完成后立即记录
6. 二进制日志处理（21:01:13）
2026-02-03T21:01:13.510976-05:00 0 [Note] Executing FLUSH NO_WRITE_TO_BINLOG BINARY LOGS2026-02-03T21:01:13.544013-05:00 0 [Note] Selecting LSN and binary log position from p_s.log_status
关键操作：
刷新二进制日志，确保日志文件切换
从performance_schema.log_status获取精确的二进制日志位置
备份当前的二进制日志文件mysql-bin.000019
7. 完成和清理（21:01:13-21:01:15）
7.1 释放锁和统计
2026-02-03T21:01:14.593663-05:00 0 [Note] Executing UNLOCK INSTANCE2026-02-03T21:01:14.594139-05:00 0 [Note] Total time Server is locked by LOCK INSTANCE FOR BACKUP is: 5.455 seconds
重要指标：
锁表总时间：5.455秒 - 这是热备份的关键优势
所有表锁已释放，数据库恢复正常操作
7.2 备份元数据生成
2026-02-03T21:01:14.598173-05:00 0 [Note] MySQL binlog position: filename 'mysql-bin.000019', position '198', GTID of the last change '801dab9b-f13d-11f0-bfbb-080027fd316d:1-16393'
生成的元数据文件：
xtrabackup_binlog_info：二进制日志位置信息
xtrabackup_info：备份详细信息
backup-my.cnf：服务器配置快照
ib_buffer_pool：缓冲池状态
7.3 备份完成确认
如无异常，则会出现备份完成的信号
2026-02-03T21:01:15.886071-05:00 0 [Note] completed OK!
从上面的过程可以看出，XtraBackup的巧妙之处在于它利用了InnoDB引擎自身的崩溃恢复机制。想象一下，这就像给高速行驶的汽车拍照，然后通过分析行车记录仪（redo log）来还原拍照瞬间的完整状态。下面我们根据上面的步骤及官网中补充的其他细节内容，绘制了一个较为全面的流程图，如下（如想获得高清版可联系我获取）
温馨提示： 本文所述流程基于Percona XtraBackup 8.4版本。不同版本存在细微差异，建议在生产环境部署前进行充分测试。
三、 结语
Percona XtraBackup之所以成为MySQL备份的事实标准，源于其巧妙的设计：
利用引擎特性：基于InnoDB崩溃恢复，而非暴力锁表
分层处理策略：先处理支持热备的InnoDB，最后快速处理非InnoDB表
轻量级锁定：用现代备份锁替代传统重量级锁
完整生态：支持增量备份、压缩、加密等企业级特性
对于任何运行MySQL的生产环境，掌握XtraBackup都是必备技能。它不仅能解决备份时的业务中断问题，还能在灾难恢复时快速拉起服务，真正实现“备份不扰业务，恢复快人一步”。
你是否在MySQL运维中遇到过其他有趣的问题？欢迎在留言区分享你的经历和解决方案！
关注微信公众号「数据库干货铺」，获取更多数据库运维干货。
