基于Xtrabackup对MySQL进行备库重搭

最新推荐文章于 2026-02-24 16:08:29 发布

原创最新推荐文章于 2026-02-24 16:08:29 发布 · 910 阅读

本内容遵循CC 4.0 BY-SA版权协议

该文章已生成可运行项目，

MySQL主从环境中，假设从库与主库的复制中断，且从库和主库的延迟较大又无法正常恢复（例如主库的binlog已被清空），此时我们需要重建从库，以恢复正常的复制流。我们可以基于Xtrabackup重搭MySQL 从库，核心思路是通过主库备份+恢复的方式初始化从库，随后再重新配置复制，让从库从备份点对应的binlog位点继续拉取增量日志。

备库重搭的操作步骤

1. 在主库做全量物理备份

xtrabackup --user=root --password=密码 --backup --compress --datadir=/data/mysql/mysqldata  --target-dir=/data/backup/full(备份的目标路径)

–compress: 在备份过程中对数据文件进行压缩（zst文件），可以减少存储空间。
zst文件，表示工具采用的压缩算法是Zstandard。

2.传输备份到从库

rsync -avP /data/backup/full/ root@slave:/data/backup/full

参数解释：

rsync：远程同步工具
-a：保障目标机上的文件和源文件保持一模一样的属性。
-v: 显示详细输出
-P：显示传输进度，并在中断后可以续传。
/data/bakcuo/full: 备份的输出目录
root@slave: 目标主机（从库），用root用户登录

这个命令执行完成后，将会在slave主机上得到一个/data/backup/full目录，内容和主库一致。

注意事项：

需要确保从库上/data/backup/full目录存在。
主库能免密SSH登录到从库，否则需要手动输入从库的root用户密码。

3. 解压缩备份文件

xtrabackup --decompress --target-dir=/data/backup/full

–decompose: 会在原位置解压，生成原始文件，同时保留.zst文件。

4. Prepare数据

xtrabackup --prepare --target-dir=/data/backup/full

5. 停止从库MySQL并清空原有数据

systemctl stop mysqld
rm -rf /data/mysql/mysqldata/*

6.恢复备份到目标数据目录

xtrabackup --copy-back --target-dir=/data/backup/full --datadir=/data/mysql/mysqldata
chown -R mysql:mysql /data/mysql/mysqldata

7. 配置 MySQL 使用自定义数据目录和日志目录

[mysqld]
datadir=/data/mysql/mysqldata
log-error=/data/mysql/log/mysqld.log

启动MySQL：

systemctl start mysqld

8. 基于GTID重新配置主从复制

# 创建复制关系
CHANGE MASTER TO
  MASTER_HOST='10.10.xxx.xx',
  MASTER_USER='repl',
  MASTER_PASSWORD='repl_pass',
  MASTER_AUTO_POSITION=1;

# 开启复制
START SLAVE;

# 查看复制状态
show replica status;

补充说明

我们观察xtrabackup --backup命令执行数据库全量备份后生成的文件，可以看到一些文本文件。我们来分析下几个文件的内容和作用。

xtrabackup_info
xtrabackup_binlog_info
xtrabackup_checkpoints
xtrabackup_tablespaces
xtrabackup_logfile

![[Pasted image 20250826140407.png]]

还有一个backup-my.cnf文件
![[Pasted image 20250826150306.png]]

xtrabackup_info

cat xtrabackup_info
uuid = 56f616d1-822a-11f0-8b79-0022a593688b 
name =
tool_name = xtrabackup
tool_command = --backup --compress --target-dir=/data/mysqlbackup --datadir=/data/mysql/mysqldata --user=gm_backup --password=...
tool_version = 8.0.35-31
ibbackup_version = 8.0.35-31
server_version = 8.0.33
start_time = 2025-08-26 02:55:03
end_time = 2025-08-26 03:11:20
lock_time = 1
binlog_pos = filename 'mysql-bin.000843', position '237', GTID of the last change '230e8ddf-5bff-11f0-854d-0022a593688b:1-17652424,f560ea3e-5bf5-11f0-8087-00220ee6d135:1-9546971'
innodb_from_lsn = 0
innodb_to_lsn = 1757984572191
partial = N # 不是部分表备份
incremental = N # 不是增量备份
format = file # 文件格式
compressed = compressed # 备份经过了压缩
encrypted = N # 未加密

_{={red}xtrabackup_info文件是Xtrabackup全量备份的元信息文件=}，它记录了备份的来源、状态、时间等信息，便于备份管理。

uuid: 备份自身的唯一标识UUID
tool*: 记录备份的工具、命令和版本
server_version: MySQL主库版本，ibbackup_version和server_version应该保持兼容。
lock_time：表示在备份过程中持有的表锁的秒数。对于Innodb的热备份通常非常短，因为redo log+mvcc可以保持一致性。
binlog_pos: filename/position记录备份时主库的二进制日志位置，备份时最后一个事务对应的gtid，恢复从库时会用到这些信息来定位复制位点。
*lsn： lsn是innodb内部redo log的日志序列号，备份文件覆盖从0到1757984572191的redo log，–prepare阶段会使用这个范围回放redo log，保证备份一致性。

xtrabackup_binlog_info

cat xtrabackup_binlog_info 
mysql-bin.000843 237 230e8ddf-5bff-11f0-854d-0022a593688b:1-17652424,f560ea3e-5bf5-11f0-8087-00220ee6d135:1-9546971

_{={red}xtrabackup_binlog_info是备份时复制信息的快照，用于配置从库复制的起点。=}
内容解析：

当前 binlog 文件名（传统复制用）
binlog position（传统复制用）
GTID 集合（GTID 复制用）
当前 binlog 文件名（传统复制用）

xtrabackup_checkpoints

cat xtrabackup_checkpoints 
backup_type = full-backuped 
from_lsn = 0 
to_lsn = 1757984572191 
last_lsn = 1758048994622 
flushed_lsn = 1757974111791 
redo_memory = 0 
redo_frames = 0

1. 备份类型 (`backup_type`)

full-backuped → 完整备份
incremental → 增量备份

2. 备份状态 (`state`)

prepared / not-yet-prepared
prepared 表示备份已经过 --prepare 处理，可以直接恢复
not-yet-prepared 表示备份刚完成，还没应用 redo log，需要 --prepare

3. LSN 范围

from_lsn → 备份开始时的 LSN
to_lsn → 备份结束时的 LSN
last_lsn → 备份中最后的 LSN，用于增量备份的起点

xtrabackup_logfile

用途
- 里面包含 在备份期间 InnoDB redo log 的副本
- 用于 --prepare 阶段回放 redo log，使备份数据变得一致
文件大小影响
- 文件越大 → redo log 越多 → --prepare 阶段需要处理的事务越多 → 耗时越久
与备份类型的关系
- 全量备份：记录备份期间所有 redo log
- 增量备份：记录增量期间 redo log
- --prepare 会把 redo log 应用到数据文件中，保证恢复的数据是 一致的、可用的
注意事项
- 这个文件只是 备份时的 redo log 副本，不是 MySQL 运行时的 redo log
- --prepare 仅在备份目录中操作，不会影响正在运行的 MySQL