备份恢复与高可用方案

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

1. 备份策略设计

1.1 备份维度

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 逻辑备份对比

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 方案对比

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 定期演练计划

7.2 恢复时间目标

8. 总结

数据库备份与高可用是系统工程：

防护层次（从外到内）：

异地备份（S3/磁带）         ← 灾难恢复（地震/火灾）
      │
延迟从库（1h delay）         ← 防误操作
      │
实时主从复制                 ← 高可用切换
      │
半同步复制                   ← 防主库宕机丢数据
      │
每日全量 + Binlog 归档       ← 时间点恢复

核心原则：

1. 备份必须验证：未验证的备份等于没有备份
2. 恢复必须演练：每季度至少一次完整恢复演练
3. RTO/RPO 必须量化：明确业务容忍度，匹配相应方案
4. 监控必须到位：复制延迟、备份成功率、Binlog 完整性

高可用架构没有银弹，MHA 已停止更新，推荐使用 Orchestrator 或原生 Group Replication + MySQL Router/ProxySQL 组合。