MySQL 备份与恢

适用 MySQL 8.x、生产环境、Kubernetes、物理/逻辑备份场景。

1. 为什么备份是核心运维

防止误删数据、误操作
防止硬件崩溃、磁盘损坏
防止被勒索病毒破坏
防止程序 Bug 覆盖数据
业务连续性（RPO、RTO 指标）

核心原则：没有恢复验证的备份 = 没备份。

2. MySQL 常见备份类型（总体结构）

MySQL 备份分为 3 类：

类型	工具	特点	是否可热备
逻辑备份	mysqldump / mydumper	SQL 文本	✅ 热备
物理备份	XtraBackup	二进制页文件拷贝	✅ 热备（最常用）
快照备份	LVM snapshot / ZFS / Ceph	秒级快照	✅ 热备

建议：生产级统一采用 XtraBackup + Binlog + 周期全量/增量。

3. 逻辑备份（mysqldump / mydumper）

适合：小业务、可读性高、跨版本迁移。

3.1 mysqldump（轻量级逻辑备份）

常用命令：

🔸 全库备份

mysqldump -uroot -p --single-transaction --master-data=2 --all-databases > full.sql

必加参数解释（增强版）

参数	用途
–single-transaction	InnoDB 热备不锁表（必须加）
–master-data=2	记录当前 binlog 位点，用于恢复复制
–skip-lock-tables	防止 MyISAM 锁表
–set-gtid-purged=OFF	适用 GTID 环境避免冲突
–hex-blob	防止 blob 出错

速度慢，适用于小库、结构导出。

3.2 mydumper（高性能逻辑备份）

mydumper = 加速版 mysqldump（多线程、高速）

备份

mydumper -u root -p pass \
--outputdir=/backup \
--threads=8 \
--compress \
--build-empty-files \
--trx-consistency-only

恢复

myloader -u root -p pass \
--directory=/backup \
--threads=16

速度可达 mysqldump 的 10 倍。

4. 物理备份（XtraBackup）—- 生产必用

XtraBackup = Percona 的 MySQL 热备工具

特点：

热备，不锁写
支持全量+增量
支持恢复 binlog 位点
恢复速度极快

4.1 全量备份（最常用）

xtrabackup --backup \
--target-dir=/backup/full \
--user=root --password=123456

4.2 增量备份

第一天：

xtrabackup --backup \
--target-dir=/backup/inc1 \
--incremental-basedir=/backup/full

第二天：

xtrabackup --backup \
--target-dir=/backup/inc2 \
--incremental-basedir=/backup/inc1

4.3 备份后的准备（apply log）

恢复前必须执行：

全量：

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

全量 + 增量：

xtrabackup --prepare --apply-log-only --target-dir=/backup/full
xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc1
xtrabackup --prepare --target-dir=/backup/full --incremental-dir=/backup/inc2

4.4 恢复

systemctl stop mysql

xtrabackup --copy-back --target-dir=/backup/full

chown -R mysql:mysql /var/lib/mysql

systemctl start mysql

恢复速度快，适合 TB 级数据。

5. Binlog 备份（增量恢复关键）

事务级恢复、误删恢复必须使用 binlog。

开启：

log_bin = mysql-bin
binlog_format = ROW
sync_binlog = 1

查看 binlog：

mysqlbinlog mysql-bin.000123 | less

6. 常见恢复场景（增强版）

场景 1：误删表（DROP TABLE）

流程：

找到最近全量备份
恢复到临时 MySQL 实例
使用 binlog point-in-time 恢复到 drop 之前
导出数据
导入正式库

命令：

mysqlbinlog --start-datetime="2025-01-10 10:00:00" \
--stop-datetime="2025-01-10 11:00:00" \
mysql-bin.000023 > recover.sql

mysql < recover.sql

场景 2：误删行（DELETE）

恢复同样使用 binlog：

mysqlbinlog --start-position=12345 --stop-position=56789 \
mysql-bin.000024 > recover.sql

场景 3：搭建主从复制（用备份恢复）

推荐使用：

mysqldump --master-data=2

或

xtrabackup --binlog-info=on

恢复后：

CHANGE MASTER TO
MASTER_HOST='master',
MASTER_USER='repl',
MASTER_PASSWORD='xxx',
MASTER_LOG_FILE='mysql-bin.000123',
MASTER_LOG_POS=45678;
START SLAVE;

7. 一致性备份（非常重要）

生产环境必须保证一致性。

方案：

方法	一致性	说明
mysqldump + single-transaction	✅	最简单
XtraBackup	✅	最推荐
LVM snapshot	✅	秒级快照，要求业务暂停写入 1ms
MGR / PXC 多副本	✅	建议基础架构层级实现

强一致性优先级：XtraBackup > LVM > mysqldump

8. 自动化备份策略（企业级）

8.1 每日全量备份 + 秒级 Binlog

每天 02:00 全量备份
每 5 分钟 binlog 备份
保留 7～30 天

8.2 冷热分离

全量备份上传对象存储（S3 / OSS / MinIO）
binlog 持续流入消息队列（Kafka / Pulsar）

8.3 Kubernetes 环境

容器内备份方式：

sidecar 备份容器
CronJob + PVC
MinIO 远程备份

9. 备份校验（不能忽略）

检查两项：

文件完整性

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

可恢复性

恢复到独立 MySQL 实例中验证。

企业要求：

每周必须执行一次恢复验证
每月必须对全量备份做一次深度恢复演练

10. MySQL 备份恢复黄金法则（最终总结）

🔥 最重要的 10 点：

备份必须支持 point-in-time 恢复（binlog）。
备份必须可恢复，而不仅是可备份。
生产库一律使用 XtraBackup。
mysqldump 不适合大表 > 50GB。
备份必须和应用写入一致（single-transaction）。
备份文件必须加压缩与校验。
备份必须离线保存（对象存储、异地备份）。
主从架构必须基于备份恢复，而不是导库。
恢复前必须 apply-log。
每次备份必须验证恢复能力，定期演练。