切换的类型与方向
复制关系是有方向的：主端接收生产写入并把数据传到从端。切换因此包含两类。计划内切换（Planned Failover 或计划内迁移）发生在业务仍受控时，先停止主端写入，把残余变化同步到从端，确认数据一致后把从端提升为主用，再把应用与网络指向新主端，最后反向重建复制关系。计划外切换发生在主端已经失效时，只能强制提升从端，未同步的数据会丢失，因此事后必须核对数据并处理原主端产生的新数据。
基本信息
| 主端 | 接收生产写入并向外发送复制数据的一端 |
|---|---|
| 从端 | 接收复制数据、处于待命状态的一端 |
| 计划内切换 | 业务可控，有准备窗口，可做到接近零丢失 |
| 计划外切换 | 主端已失效，强制提升，可能丢失未同步数据 |
| 关键步骤 | 停写、追平、验证、提升、切流量、反向复制 |
| 回切 | 原主端修复后重新同步，再按计划内流程切回 |
典型使用场景
- 机房搬迁或新阵列上线，需要在窗口内把业务整体迁移过来
- 计划内维护：先切到容灾站点承载业务，再停机检修原主端
- 容灾演练：按真实流程执行切换与回切，检验手册是否可用
- 切换后重建保护：在新主端与原从端之间重新定义复制方向
- 版本与固件升级：在新旧阵列之间来回切换，验证兼容性
- 区域供电检修：临时把业务迁移到另一站点，检修完成后回切
切换阶段与风险
| 阶段 | 关键动作 | 风险点 |
|---|---|---|
| 准备 | 确认副本状态、链路健康与回退方案 | 未确认落后量就开始切换 |
| 停写 | 应用停止写入或进入只读 | 未通知相关方导致半写状态 |
| 追平 | 把残余变化传输到从端 | 链路慢，超出切换窗口 |
| 验证 | 检查副本完整性与可挂载性 | 跳过验证直接提升 |
| 提升 | 把从端提升为主用 | 双主写入造成数据分叉 |
| 切流量 | 应用与网络指向新主端 | 连接池或 DNS 缓存未刷新 |
| 反向 | 重新建立回原主端的复制 | 忘记重建，后续长期无保护 |
计划内切换的核心是先停写再追平。只要主端还在写入，从端就永远追不平，切换窗口的长短取决于停写后剩余积压的传输时间。因此切换前的准备重点是把日常积压压到接近零，让最后一段追平在几分钟内完成。
计划外切换最常见的风险是双主。原主端并未真正失效，只是链路中断或短暂卡顿，而业务已在从端恢复写入，两端各自产生新数据后合并代价极高。引入第三方仲裁或带外确认机制，并明确主端恢复后的处置流程，可以显著降低这类风险。
计划内切换检查表
计划内切换检查表
# [ ] 复制状态正常，落后时间在阈值内
# [ ] 已通知业务方进入停写或只读窗口
# [ ] 主端停止写入，确认无未提交事务
# [ ] 等待从端追平，核对落后量归零
# [ ] 校验副本可挂载、可启动业务
# [ ] 提升从端为主用，切换应用与网络指向
# [ ] 建立反方向复制，恢复原有保护级别