容灾演练核心是验证“切得对、稳、可回”，需在不扰生产前提下真实测rpo=0和rto≤30秒；关键包括：一、分级场景（本地/机房/数据级）明确目标；二、隔离环境（影子流量+旁路验证）；三、自动化验证（rpo/rto数据化闭环）；四、常态化机制（静默/灰度/断电演练）。
设计安全可靠的容灾演练方案，核心不是“能不能切”，而是“切得对不对、切得稳不稳、切完能不能回”。它必须在不干扰生产业务的前提下，真实验证RPO=0和RTO≤30秒等关键指标。以下四点是落地关键。
明确演练目标与分级场景
避免“为演而演”。每次演练前需定义清晰的业务目标和故障注入粒度：
- 本地故障级：模拟单BE节点宕机、FE Master失联、网络抖动（如丢包率20%），验证自动副本修复与秒级服务收敛
- 机房级：关闭整个AZ（如上海AZ1所有节点），验证跨AZ流量切换、读写路由重定向、元数据一致性
- 数据级：人为破坏某Tablet主副本存储文件，触发系统自动从Follower拉取并校验CRC，确认无静默损坏
构建隔离可控的演练环境
绝不直接在生产集群上执行破坏性操作。推荐采用“影子流量+旁路验证”模式：
- 通过镜像代理（如基于BRPC的流量复制模块）将1%生产写请求同步到演练通道，不落盘、不参与Quorum投票，仅用于观察日志同步链路是否断裂
- 在灾备中心部署轻量级验证服务，定时执行
SELECT COUNT(*) FROM tablet_health WHERE state != 'HEALTHY'，比对主中心健康视图，提前暴露同步延迟或元数据漂移 - 所有演练操作必须带时间戳标记与操作人签名，记录在审计日志中，支持事后追溯
自动化验证与结果闭环
人工判断“是否恢复”不可靠，必须用数据说话：
- RPO验证：比对主中心最新事务ID与灾备中心对应Tablet的
max_commit_version，差值为0才视为达标 - RTO验证：从触发故障开始计时，到监控系统显示
SHOW PROC '/cluster_health/cluster_state'中所有节点状态为AVAILABLE且查询延迟回归基线（±10%），即为完成时间 - 每次演练后自动生成报告，包含异常告警数、副本修复耗时分布、最大查询P99延迟波动，未达标项自动创建Jira任务并关联责任人
建立常态化演练机制
容灾能力会退化，必须像打补丁一样定期刷新：
- 每月一次“静默演练”：仅运行检测脚本，不触发切换，验证心跳、租约、日志同步链路连通性
- 每季度一次“灰度切换”：将非核心业务表（如日志类、报表缓存）路由至灾备中心执行读写，持续2小时，观察BE资源水位与FE元数据压力
- 每年一次“全链路断电演练”：联合基础设施团队，真实切断主中心供电（提前48小时备案），验证从物理层断电→FE自动选举→BE重新注册→应用连接池重建→业务查询返回的完整路径
