MySQLNotes

第 27 章：备份恢复

zjc 于 2026-01-27 发布

这是《MySQL 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 备份是最后一道防线。高可用可以处理机器故障，却无法自动处理误删表、错误更新、逻辑 Bug、勒索加密和版本缺陷。备份的价值只有在成功恢复后才存在。

27.1 备份目标

设计备份前先明确：

指标 问题
RPO 最多接受丢多久数据
RTO 多久必须恢复业务
保留周期 天、周、月、年分别保留多久
恢复粒度 实例、库、表、行
恢复位置 原实例、临时实例、新集群
加密要求 备份和传输如何加密
演练频率 多久验证一次

没有恢复时间目标的备份方案只是文件堆积。

27.2 备份分类

类型 说明 优点 缺点
逻辑备份 导出 SQL 或数据行 可读、跨版本较灵活 恢复慢、体积可能较大
物理备份 复制数据文件和日志 恢复快、贴近生产 版本和平台要求严格
快照备份 存储层一致性快照 速度快 依赖存储语义
增量备份 只备份变化 体积小 恢复链路复杂
Binlog 记录增量变更 支持时间点恢复 不能单独作为全量

常见组合：

每日物理全量 + Binlog 持续归档
每周核心表逻辑备份
每月恢复演练
每年归档备份离线保存

27.3 mysqldump

适合中小库、表级恢复和跨环境迁移。

全库备份：

mysqldump -h127.0.0.1 -P3306 -uroot -p \
  --single-transaction \
  --source-data=2 \
  --routines \
  --triggers \
  --events \
  --all-databases \
  > full_backup.sql

单库备份：

mysqldump -h127.0.0.1 -uroot -p \
  --single-transaction \
  --source-data=2 \
  --routines --triggers --events \
  shop > shop_backup.sql

只备份结构：

mysqldump -h127.0.0.1 -uroot -p --no-data shop > shop_schema.sql

只备份数据：

mysqldump -h127.0.0.1 -uroot -p --no-create-info shop > shop_data.sql

关键参数：

参数 说明
--single-transaction 使用一致性快照，避免 InnoDB 长锁表
--source-data=2 输出备份位点为注释
--routines 备份存储过程和函数
--triggers 备份触发器
--events 备份事件
--set-gtid-purged=OFF 恢复到独立实例时可避免 GTID 干扰

注意：备份时不要加入无关业务流量；大库逻辑备份会拉长备份窗口并影响复制。

27.4 恢复 mysqldump

创建目标库：

CREATE DATABASE shop_recovery
  DEFAULT CHARACTER SET utf8mb4;

恢复：

mysql -h127.0.0.1 -P3307 -uroot -p shop_recovery < shop_backup.sql

推荐恢复到临时实例，而不是直接覆盖生产库。恢复后验证：

SELECT TABLE_NAME, TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'shop_recovery';

抽样对比：

SELECT COUNT(*), SUM(total_amount)
FROM shop_recovery.orders
WHERE created_at >= '2026-08-01';

27.5 mydumper / myloader

大逻辑备份可以使用 mydumper：

mydumper \
  --host=127.0.0.1 \
  --user=root \
  --password='...' \
  --database=shop \
  --threads=8 \
  --trx-consistency-only \
  --outputdir=/backup/shop

恢复：

myloader \
  --host=127.0.0.1 \
  --user=root \
  --password='...' \
  --directory=/backup/shop \
  --threads=8

优点：

  1. 多线程导出导入；
  2. 表级文件分离；
  3. 便于压缩和并行恢复；
  4. 支持大库分片处理。

27.6 物理备份

XtraBackup

Percona XtraBackup 是常见开源物理备份工具：

xtrabackup \
  --backup \
  --target-dir=/backup/base \
  --user=root \
  --password='...' \
  --socket=/var/lib/mysql/mysql.sock

准备备份：

xtrabackup --prepare --target-dir=/backup/base

恢复：

systemctl stop mysql
xtrabackup --copy-back --target-dir=/backup/base
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

物理备份必须与 MySQL 版号、页大小和平台兼容，恢复前阅读对应版本文档。

Clone Plugin

MySQL 8.0 官方克隆插件适合搭建从库：

INSTALL PLUGIN clone SONAME 'mysql_clone.so';

CREATE USER 'clone_user'@'10.0.0.11' IDENTIFIED BY 'Clone123456!';
GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'10.0.0.11';

CLONE INSTANCE FROM
  'clone_user'@'10.0.0.11':3306
  IDENTIFIED BY 'Clone123456!';

查看状态：

SELECT * FROM performance_schema.clone_status;
SELECT * FROM performance_schema.clone_progress;

存储快照

云盘快照必须保证：

  1. InnoDB 处于一致性状态；
  2. 文件系统刷盘语义正确；
  3. 快照包含 Redo 和 Undo；
  4. Binlog 位点可追踪；
  5. 恢复后通过表校验。

不能假设任意时刻拷贝 .ibd 文件就是可用备份。

27.7 时间点恢复

流程：

1. 恢复全量备份到临时实例；
2. 找到备份对应 Binlog 位点或 GTID；
3. 重放 Binlog 到目标时间前；
4. 校验数据；
5. 导出需要恢复的表；
6. 人工确认后写回；

示例：

mysqlbinlog --no-defaults \
  --start-position=154 \
  --stop-position=987654 \
  mysql-bin.000010 mysql-bin.000011 \
  | mysql -h127.0.0.1 -P3307 -uroot -p shop_recovery

误操作恢复思路：

-- 在临时实例建反向表
CREATE TABLE orders_recovered LIKE orders;

从 Binlog 解析误删前的 Write_rows，或导出误删表快照，再按业务主键合并。

27.8 备份验证

每次恢复演练至少验证：

验证项 方法
实例可用 SELECT 1
表结构 SHOW CREATE TABLE
行数 核心表 COUNT
金额 SUM / 对账
索引 SHOW INDEX
关键数据 抽样对比
Binlog 位点 SHOW BINARY LOG STATUS
应用连通 应用影子环境连接
恢复耗时 全流程计时
备份完整性 校验和或压缩测试

自动化验证脚本应输出：

备份文件
大小
开始结束时间
源实例位点
恢复实例版本
核心表行数
校验结果
恢复耗时
负责人

27.9 备份安全

  1. 传输使用 TLS；
  2. 存储使用对象存储服务端加密和客户自主密钥；
  3. 备份账号只授予必要权限；
  4. 生产库凭据放密钥系统；
  5. 访问审计；
  6. 防止恢复脚本泄漏密码；
  7. 异地保存；
  8. 设置对象版本和防删锁；
  9. 定期清理但仍满足保留策略；
  10. 测试密钥可用性。

备份密码、云 KMS 权限和数据库凭据必须分开管理，避免一个账号同时能删数据和删备份。

27.10 备份调度

示例策略：

频率 内容
每 15 分钟 Binlog 归档
每日 物理全量或快照
每周 核心库逻辑备份
每月 恢复演练
每季度 异地恢复演练
每年 合规归档

调度必须避开：

  1. 业务高峰；
  2. 大型批处理；
  3. DDL 窗口；
  4. 备份从库正在追赶复制；
  5. 其他备份任务重叠。

27.11 常见故障

问题 原因 处理
备份期间主从延迟 IO 压力或大事务 低峰执行、限速、换专用从库
恢复到一半失败 SQL 错误、字符集、权限 保存日志，先在临时实例重放
Binlog 缺失 被提前清理 检查保留策略，寻找归档
备份文件损坏 传输或磁盘错误 校验和、多副本
GTID 冲突 恢复实例已有事务 使用干净实例和正确参数
恢复后数据不一致 位点错误 重新确认备份位点
压缩无法解压 工具版本 保留工具版本记录

本章小结

备份方案应围绕 RPO 和 RTO 设计，常见组合是全量物理备份加 Binlog 归档。逻辑备份适合小库和表级恢复，物理备份适合快速重建实例。所有备份都必须恢复到临时环境并验证行数、金额、结构和位点，否则不能称为可用备份。

思考题

  1. mysqldump --single-transaction 的作用是什么？
  2. 为什么不能直接拷贝运行中的 .ibd 文件作为备份？
  3. 时间点恢复需要哪些输入？
  4. 如何验证一个备份真的可恢复？
  5. 设计一个每日备份和月度演练的自动化流程。