19.9.4 灾备架构模式与RPO/RTO规划

本节聚焦灾备架构模式与RPO/RTO规划方法，建立从业务分级、技术选型到实施与验证的完整思路，确保灾难场景下业务连续性可量化、可落地，并配套可执行示例、安装与排错流程。

1. 灾备目标与指标定义#

RPO（恢复点目标）：可容忍的数据丢失窗口，决定同步/异步复制策略与日志保留策略。
RTO（恢复时间目标）：可容忍的业务中断时间，决定切换自动化程度与基础设施准备程度。
RCO/MTTR：配置恢复目标与平均修复时间，补充RTO的运维可执行性。
业务分级：按业务影响和监管要求划分P0/P1/P2，映射不同RPO/RTO标准。

示例：业务分级与RPO/RTO模板

# /opt/dr/biatargets.yaml
services:
  pay-core:
    level: P0
    rpo: "1s"
    rto: "1m"
  order-api:
    level: P1
    rpo: "5m"
    rto: "15m"
  report:
    level: P2
    rpo: "30m"
    rto: "2h"

说明：用于在演练与监控中作为目标基线（SLO）。

2. 灾备架构模式#

冷备（Cold Standby）：资源成本低，RTO长（小时级），RPO取决于备份频率。
温备（Warm Standby）：核心组件预部署并保持同步，RTO中等，RPO分钟级。
热备（Hot Standby / Active-Standby）：实时复制、自动故障切换，RTO分钟级甚至秒级，RPO接近0。
双活（Active-Active）：多活流量分担与一致性治理，RTO秒级，RPO趋近0。
同城双中心/两地三中心/多活多中心：覆盖不同容灾半径与延迟约束。

原理草图：典型两地三中心

安装与基础环境准备（以CentOS为例）

# 1) 安装基础工具
yum install -y rsync chrony net-tools lsof

# 2) 配置时间同步（灾备复制对时间偏差敏感）
systemctl enable --now chronyd
chronyc sources -v

预期效果：chrony已启动，chronyc sources -v 显示可用上游源。

3. RPO/RTO规划方法#

业务影响评估（BIA）：明确中断成本、合规要求、上下游依赖。
分级指标落地：映射到数据库复制方式、应用切换机制、消息系统与配置中心策略。
一致性与性能权衡：同步复制保障RPO但提升延迟；异步复制降低延迟但放大RPO风险。
网络与存储约束评估：带宽、延迟、抖动影响复制与恢复速度。

示例：RPO/RTO评估表（命令生成报表）

cat > /opt/dr/rpo_rto_eval.csv <<'EOF'
service,level,rpo_target,rto_target,db_mode,notes
pay-core,P0,1s,1m,semi-sync,双机房心跳
order-api,P1,5m,15m,async,灰度回切
report,P2,30m,2h,backup-only,每日快照
EOF

column -t -s, /opt/dr/rpo_rto_eval.csv

预期效果：输出对齐的规划表，便于评审与备案。

4. 关键组件灾备策略指引#

数据库（MySQL/ProxySQL）：半同步/全同步复制、GTID、延迟复制防误操作扩散；主从切换流程自动化。
缓存（Redis）：AOF/复制/哨兵/集群多机房部署，注意缓存穿透与回源压力。
消息系统（Kafka）：多副本、跨机房复制（MirrorMaker），关注消费位点一致性。
配置与注册中心（Nacos/ZooKeeper）：多机房集群与仲裁设计。
负载与流量层（Nginx/HAProxy/Keepalived）：DNS/Anycast/全局流量调度，健康检查精细化。

MySQL 半同步示例（主从）

# 主库安装插件并开启半同步
mysql -uroot -p -e "INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';"
mysql -uroot -p -e "SET GLOBAL rpl_semi_sync_master_enabled=1;"

# 从库安装插件并开启半同步
mysql -uroot -p -e "INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';"
mysql -uroot -p -e "SET GLOBAL rpl_semi_sync_slave_enabled=1;"

# 检查状态
mysql -uroot -p -e "SHOW STATUS LIKE 'Rpl_semi_sync%';"

关键参数说明：
- rpl_semi_sync_master_enabled：主库开启半同步等待至少一个从库ACK。
- Rpl_semi_sync_master_status=ON：表示当前处于半同步有效状态。

Redis AOF 与复制示例

# /etc/redis.conf 关键配置
appendonly yes
appendfsync everysec
replicaof 10.0.1.10 6379

# 重启服务并验证
systemctl restart redis
redis-cli info replication

预期效果：role:slave 且 master_link_status:up。

Kafka 跨机房复制（MirrorMaker2）简化配置

# /opt/kafka/mm2.properties
clusters = primary,dr
primary.bootstrap.servers = 10.0.1.10:9092
dr.bootstrap.servers = 10.0.2.10:9092
primary->dr.enabled = true
primary->dr.topics = .*

# 启动 MirrorMaker2
/opt/kafka/bin/connect-mirror-maker.sh /opt/kafka/mm2.properties

预期效果：DR集群出现与主集群一致的主题与数据。

Nginx 健康检查与切换示例

# /etc/nginx/conf.d/upstream.conf
upstream app_backend {
  server 10.0.1.20:8080 max_fails=3 fail_timeout=5s;
  server 10.0.2.20:8080 backup;
}

nginx -t && systemctl reload nginx

预期效果：主节点故障时自动切至备节点。

5. 典型RPO/RTO目标参考#

P0核心交易：RPO ≤ 1秒，RTO ≤ 1分钟
P1关键业务：RPO ≤ 5分钟，RTO ≤ 15分钟
P2一般业务：RPO ≤ 30分钟，RTO ≤ 2小时
P3非关键业务：RPO ≤ 24小时，RTO ≤ 24小时

示例：Prometheus 监控复制延迟（MySQL）

# /etc/prometheus/targets.yml
- targets:
  - "10.0.1.10:9104"   # mysqld_exporter
  - "10.0.2.10:9104"

指标建议：mysql_slave_status_seconds_behind_master 作为RPO风险指标。

6. 切换与恢复流程设计#

切换策略：自动切换为主，人工审批为辅；预定义回切流程与变更窗口。
数据一致性校验：校验点、校验策略、数据重放与补偿机制。
回切与降级：灾后回切需灰度、限流与数据对齐。

故障切换流程示例（MySQL 主从）

# 1) 在从库提升为主库
mysql -uroot -p -e "STOP SLAVE; RESET SLAVE ALL;"

# 2) 应用侧切换连接（示例为 ProxySQL）
mysql -uadmin -padmin -h 127.0.0.1 -P6032 -e "
UPDATE mysql_servers SET status='OFFLINE_SOFT' WHERE hostgroup_id=10 AND hostname='10.0.1.10';
UPDATE mysql_servers SET status='ONLINE' WHERE hostgroup_id=10 AND hostname='10.0.2.10';
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;"

预期效果：业务连接切至新主库，旧主库下线。

数据一致性校验示例（pt-table-checksum）

# 安装 Percona 工具
yum install -y percona-toolkit

# 校验主从一致性
pt-table-checksum --host=10.0.2.10 --user=root --password=pass \
  --replicate=percona.checksums --databases=appdb

7. 风险与成本控制#

成本模型：热备/双活成本高，需结合业务价值与风险承受度。
复杂度控制：多活架构需治理数据冲突、全局唯一性与跨区事务。
合规要求：金融/政务需满足异地容灾与数据留存规范。

成本与复杂度评估表（示例）

模式        成本  复杂度  适用等级
冷备        低    低      P2/P3
温备        中    中      P1
热备        高    高      P0
双活        很高  很高    P0(核心)

8. 验证与持续优化#

定期演练验证RPO/RTO达成情况，演练结果入库沉淀为改进项。
监控复制延迟、故障切换时间与恢复成功率，建立可视化看板。
结合业务变化动态调整目标与架构。

演练脚本示例（简化版）

#!/usr/bin/env bash
# /opt/dr/drill.sh
set -e
echo "[1/4] 模拟主库故障"
systemctl stop mysql

echo "[2/4] 观察从库提升流程（示例人工）"
mysql -uroot -p -h10.0.2.10 -e "SHOW SLAVE STATUS\G"

echo "[3/4] 记录切换时间"
date +"%F %T" >> /opt/dr/drill.log

echo "[4/4] 恢复主库"
systemctl start mysql

排错清单
- 复制延迟过高：检查带宽与延迟（ping/iperf3），确认半同步等待超时配置。
- 切换失败：验证服务健康探测与VIP漂移（ip a，systemctl status keepalived）。
- 数据不一致：执行校验工具，检查应用写入双活冲突。

练习
1. 使用本节模板为三类业务写出RPO/RTO目标，并给出对应的复制模式。
2. 在测试环境搭建MySQL主从半同步，记录从库Seconds_Behind_Master变化。
3. 模拟主库停机，完成手工切换并记录RTO，输出演练报告。