回切 Failback
原故障侧修复后把服务切回来的过程。它比首次切换更麻烦：需要先把原侧以从角色重新加入复制拓扑、追平延迟、确认数据一致，再在计划窗口内执行角色切换。很多团队的演练只做切出去、不做切回来，结果真故障恢复后长期运行在降级拓扑上，风险一直被保留。
基本信息
| 顺序 | 恢复复制关系（从角色）→ 追平延迟 → 再切换角色 |
|---|---|
| 窗口 | 通常放业务低峰并提前预告 |
| 验证 | 与首次切换使用同一套验证清单 |
| 前置 | 原侧故障已排除并稳定运行观察过一段时间 |
典型使用场景
- 机房或节点故障修复后的计划性回归
- 计划维护结束：临时切换到备侧后按窗口切回
- 容量恢复：备侧资源不足以长期承载时的回切
- 合规要求：主备机房的角色需要恢复到常态布局
- 演练完整闭环：切出去与切回来都要验证，才算一次完整演练
回切检查要点
回切检查要点
# 1 故障排除：原侧硬件、网络、存储问题已修复，并稳定观察一至两周
# 2 重建复制：原侧以从角色加入，确认复制线程正常、无报错
# 3 追平数据：复制延迟归零，关键表行数与校验和一致
# 4 窗口确认：低峰时段、相关方已通知、回退方案已准备
# 5 执行切换：按预案切换角色并更新连接入口（DNS / VIP / 监听器）
# 6 业务验证：冒烟用例、关键对账、监控指标回归正常
# 7 保留能力：保留『再切回』的操作手册与责任分工回切与首次切换差异
| 维度 | 首次切换 | 回切 |
|---|---|---|
| 数据方向 | 正向同步为主 | 需要反向重建同步关系 |
| 数据差异 | 备侧数据完整 | 两侧可能存在独立写入产生的分叉 |
| 时间压力 | 故障紧急，尽快恢复 | 可按窗口从容安排 |
| 心理预设 | 预案熟悉 | 常被当成简单操作而漏步骤 |
回切涉及数据反向同步与拓扑重建，难度不低于切换。若两侧在故障期间都产生过写入，必须先做数据比对与冲突处理，再决定以哪一侧为准。
不要在两侧数据未追平的情况下急于回切：新产生的数据差异会带来二次不一致，且更难定位修复。