深入面试场景：为什么XtraBackup比mysqldump更适合生产环境？

俊才

发布于 2026-02-04 14:33:18

810

在这个数据为王的时代，备份做不好，年终奖怕是都要打水漂。

已经看过很多系统的数据备份是使用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 --version
2026-02-03T03:42:32.338476-05:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --datadir=/var/lib/mysql 
bin/xtrabackup version 8.4.0-2 based on MySQL server 8.4.0 Linux (x86_64) (revision id: d4373834)

2. 进行备份

2.1 创建数据库账号并授权

根据官方文档说明（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/bash
IPADDRESS='192.168.56.102'
PORT=3306
BACKUP_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}/dbbackup

rm -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 {} \;
else
    echo "备份失败：$(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: 3306
2026-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/data
2026-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 transfer
2026-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 LOGS
2026-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 INSTANCE
2026-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!

8. XtraBackup的核心工作流程总结

从上面的过程可以看出，XtraBackup的巧妙之处在于它利用了InnoDB引擎自身的崩溃恢复机制。想象一下，这就像给高速行驶的汽车拍照，然后通过分析行车记录仪（redo log）来还原拍照瞬间的完整状态。下面我们根据上面的步骤及官网中补充的其他细节内容，绘制了一个较为全面的流程图，如下（如想获得高清版可联系我获取）