备份恢复与高可用方案

Thu, 13 Aug 2026 11:35:00 +0800

数据是企业最核心的资产。完善的备份恢复策略与高可用架构是保障数据安全、业务连续性的底线工程。本文系统讲解 MySQL 备份恢复方案与高可用架构选型。

1. 备份策略设计

1.1 备份维度

维度	策略	RPO	RTO
全量备份	每周/每日全备	24h	小时级
增量备份	XtraBackup 增量 + Binlog	小时级	分钟级
实时复制	主从同步 + Binlog	秒级	秒级
跨地域备份	异地机房/云存储	取决于同步	分钟级

1.2 321 备份原则

3 份数据副本
2 种不同存储介质
1 份异地备份

2. 物理备份：Percona XtraBackup

2.1 特点

热备份：不锁表或只锁很短时间
支持增量备份
支持流式压缩备份
支持并行备份

2.2 全量备份

# 全量备份
xtrabackup --backup --target-dir=/backup/full/$(date +%Y%m%d) \
 --user=backup --password=xxx --host=localhost

# 备份过程：
# 1. 拷贝 InnoDB 数据文件（不锁表）
# 2. 执行 FLUSH TABLES WITH READ LOCK（FTWRL）复制非 InnoDB 文件
# 3. 记录 Binlog 位点（用于恢复时点）
# 4. 解锁

2.3 增量备份

# 周日全量
xtrabackup --backup --target-dir=/backup/full

# 周一增量（基于周日全量）
xtrabackup --backup --target-dir=/backup/inc1 \
 --incremental-basedir=/backup/full

# 周二增量（基于周一增量）
xtrabackup --backup --target-dir=/backup/inc2 \
 --incremental-basedir=/backup/inc1

# 恢复：准备（apply log）→ 合并 → 恢复
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

# 拷贝恢复
xtrabackup --copy-back --target-dir=/backup/full \
 --datadir=/var/lib/mysql

2.4 流式备份到远程

# 压缩流式备份到远程
xtrabackup --backup --stream=xbstream --compress \
 | ssh backup-server "xbstream -x -C /backup/"

# 或使用 nc/socat

3. 逻辑备份：mysqldump / mydumper

3.1 mysqldump

# 全库逻辑备份（单线程，适合小库）
mysqldump -u root -p --all-databases --single-transaction \
 --routines --triggers --events > full_backup.sql

# 关键参数：
# --single-transaction: 开启事务一致性备份（InnoDB）
# --master-data=2: 记录 Binlog 位点到注释
# --quick: 不缓存全表到内存（大表必选）
# --where: 条件备份

3.2 mydumper（多线程逻辑备份）

# 多线程备份（推荐大库）
mydumper -u root -p xxx -B mydb -t 4 -o /backup/mydumper/

# -t 4: 4 个线程
# 输出：每个表一个文件 + metadata（Binlog 位点）

# 恢复
myloader -u root -p xxx -d /backup/mydumper/ -t 4 -B mydb

3.3 物理 vs 逻辑备份对比

维度	物理备份（XtraBackup）	逻辑备份（mysqldump）
速度	快（文件拷贝）	慢（逐行导出）
大小	紧凑（数据文件）	较大（文本+INSERT）
恢复速度	极快	慢
跨版本	有限制	兼容性好
部分恢复	难	容易（单表恢复）
增量备份	支持	不支持
适用	大库、生产环境	小库、数据迁移

4. 基于 Binlog 的 PITR（时间点恢复）

4.1 原理

全量备份（周日 00:00）
 │
 ▼
恢复全量 ──► 应用增量（周一、周二）
 │
 ▼
 应用 Binlog（精确到秒）
 │
 ▼
 恢复到"误删前 1 秒"

4.2 恢复步骤

# 1. 恢复全量 + 增量（见上节）

# 2. 查找目标 Binlog 文件和位点
mysqlbinlog /var/lib/mysql/binlog.000042 | grep -i "DROP TABLE"
# 找到误操作的位点：2024-01-15 14:30:25

# 3. 应用 Binlog 到目标位点前
mysqlbinlog --start-position=xxx --stop-datetime="2024-01-15 14:30:24" \
 /var/lib/mysql/binlog.000042 /var/lib/mysql/binlog.000043 \
 | mysql -u root -p

4.3 延迟从库（预防误操作最佳实践）

# 配置延迟从库（延迟 1 小时）
[mysqld]
replica_parallel_workers = 4

CHANGE REPLICATION SOURCE TO
 SOURCE_DELAY = 3600; -- 延迟 3600 秒

# 误操作后可快速从延迟从库恢复

5. 高可用架构方案

5.1 主从复制（基础）

Master ──► Binlog ──► Slave
 │ │
 │ └── 只读查询、备份
 └── 写请求

复制模式：
- 异步复制：Master 不等待 Slave 确认（默认，可能丢数据）
- 半同步复制：Master 等至少一个 Slave ACK（减少丢数据风险）
- 组复制：Multi-Master（MySQL 8.0 Group Replication）

5.2 MHA（Master High Availability）

架构：
Manager 节点（监控+决策）
 │
 ├── Master (写)
 ├── Slave1 (候选新主)
 └── Slave2 (从)

故障检测：Manager 定期 ping 所有节点
故障转移：
 1. 检测到 Master 不可达
 2. 从 Slaves 中选举最新数据的节点
 3. 应用差异 Binlog（relay log）
 4. 提升为新的 Master
 5. 其他 Slaves 重新指向新 Master
 
切换时间：通常 10-30 秒

局限：Manager 单点、需要 SSH 免密、只支持一主多从

5.3 Orchestrator（推荐）

优势（相比 MHA）：
1. 可视化拓扑管理（Web UI）
2. 支持 GTID 和普通复制
3. 可以处理复杂拓扑（级联复制）
4. sophisticated 故障检测（避免网络抖动误判）
5. 手工/自动故障转移都支持
6. 支持 Pre-failover hooks（自定义逻辑）

部署：
docker run -d --name orchestrator \
 -p 3000:3000 \
 openarkcode/orchestrator

关键配置：
"RecoveryMasterPromotionIgnoreHostnameFilters": [],
"RecoverMasterClusterFilters": [".*"],
"RecoveryPeriodBlockSeconds": 3600 # 故障恢复后禁止再次切换的时间

5.4 MySQL Group Replication（MGR）

原生高可用（MySQL 5.7+）：

Primary-Secondary 模式：
 Primary: 读写
 Secondary × N: 只读（自动复制）
 
 Primary 故障 → 自动选举新 Primary（基于 Paxos 算法）

Multi-Primary 模式：
 多个节点都可读写
 冲突检测：Certification-based
 局限：不支持 SERIALIZABLE、外键需小心

配置要点：
group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
group_replication_local_address = "node1:33061"
group_replication_group_seeds = "node1:33061,node2:33061,node3:33061"
group_replication_single_primary_mode = ON

5.5 方案对比

方案	自动故障转移	数据一致性	复杂度	适用
主从手动	❌	异步	低	非核心系统
MHA	✅	半同步可选	中	中大型系统
Orchestrator	✅	配置灵活	中	推荐方案
MGR	✅	强一致（多数派）	中	MySQL 8.0+
MySQL Router	✅	取决于后端	低	配合 MGR
ProxySQL	✅	配置灵活	中	读写分离 + 故障转移

6. 读写分离架构

 ┌──► Read Replica 1
App ──► ProxySQL ├──► Read Replica 2
 │ (读负载均衡)
 └──► Master (写)
 
ProxySQL 规则：
- SELECT ... FOR UPDATE → Master
- SELECT * FROM ... → Replica
- INSERT/UPDATE/DELETE → Master
- 自定义规则（按用户、Schema、查询 pattern）

7. 灾难恢复演练

7.1 定期演练计划

演练类型	频率	内容
全量恢复	每季度	从备份恢复到测试环境，验证可用
PITR 恢复	每半年	恢复到指定时间点，验证精度
故障切换	每月	模拟主库宕机，验证自动切换
跨区域恢复	每年	从异地备份恢复完整环境

7.2 恢复时间目标

分级	RTO	RPO	方案
核心业务	< 5min	< 1min	MGR + 异地热备
重要业务	< 30min	< 1h	MHA/Orchestrator + Binlog
一般业务	< 4h	< 24h	定时备份 + 手动恢复

Recovery on PlumePHP

备份恢复与高可用方案

1. 备份策略设计

1.1 备份维度

1.2 321 备份原则

2. 物理备份：Percona XtraBackup

2.1 特点

2.2 全量备份

2.3 增量备份

2.4 流式备份到远程

3. 逻辑备份：mysqldump / mydumper

3.1 mysqldump

3.2 mydumper（多线程逻辑备份）

3.3 物理 vs 逻辑备份对比

4. 基于 Binlog 的 PITR（时间点恢复）

4.1 原理

4.2 恢复步骤

4.3 延迟从库（预防误操作最佳实践）

5. 高可用架构方案

5.1 主从复制（基础）

5.2 MHA（Master High Availability）

5.3 Orchestrator（推荐）

5.4 MySQL Group Replication（MGR）

5.5 方案对比

6. 读写分离架构

7. 灾难恢复演练

7.1 定期演练计划

7.2 恢复时间目标

8. 总结