导读：切换常被理解为一次单点切换：改连接串、放量、观察，而工程上它是一串有时序依赖的动作，每个动作都有进入条件、判据和回退点。Stripe 把关键阶段定在一次主库故障切换的时长以内，OceanBase 的迁移工具把正向切换拆成八步、给出 15 秒的延迟阈值。这些做法指向同一件事：切换与回退可以写成带阈值和时点的条件，而不是"确认正常"。
一、切换的时长有参照物
Stripe 在 2024 年公开的 DocDB 迁移平台承载每秒 500 万次查询、2,000 多个分片，2023 年迁走 1.5 PB 数据，应用侧没有感知。它的迁移目标写得具体：关键阶段要短于一次计划内的主库故障切换，通常为几秒，并与应用的重试预算一致。应用本来就为主库切换设计了重试，停写窗口不超过这个量级就能被覆盖，"业务能忍多久"因此可以从既有演练记录里取数。
实现方式也印证了这一点：请求携带版本令牌，分片只服务比自身记录更新的请求；切换时先提升令牌号，读写立即被拒，等复制服务追平在途写入，再更新路由，全程两秒内完成。停写由此不是组织动作，而是由被切换一方执行、可观测、可恢复的状态；"请业务停一下"只是发起，判据要看旧库是否真的不再接受写入。
跨引擎迁移的窗口没有这么短，结构却相同：Oracle 迁到国产或开源数据库，存量与增量要走日志解析，对象要单独处理；OMS 社区版把正向切换拆成八步，预检查给出 15 秒的增量延迟阈值。
二、五个属性，五类证据
图 1 把五个属性按切换的动作顺序排开。下文统一用一条示意链路：订单库从 Oracle 迁到国产库，窗口内停的是下单、支付回调与库存扣减三类写入；阈值、耗时与对象名均为示意。
图 1：五个属性分别对应切换过程中的一段动作；产出物要能归档。
停得住。应用停止写入是必要条件，不是充分条件：连接池里的空闲连接、失败重试队列、定时任务、批处理作业、未纳入清单的其他系统直连，都可能在"业务已停"之后继续写旧库。判据因此要落在旧库一侧——写入计数为零，或写权限已撤销并用测试账号验证过写入失败。Stripe 把判据下沉到存储，令牌一升旧请求即被拒；OBUS 把判据放在账号，关闭源端会话会锁定被迁移用户并杀掉现存连接。两者共同的地方是，判断由被切换的一方作出，而不是由发起方声明。
追得平。追平是速率问题：停写瞬间的位点差除以通道消化速率，才是等待时间。延迟小也不等于位点一致——延迟是时间差，位点是位置。OMS 把两者分成两步：预检查看延迟是否在 15 秒内，随后还要"确认同步追平停写位点"。
对得上。校验要在窗口内完成，又不能给源端增加负担，Stripe 因此对比时间点快照。口径要事先定：比行数、比校验和、比关键字段，还是抽样明细——口径决定耗时，也决定"通过"二字的分量。OMS 在增量基本追平后自动发起全量校验，对不一致的数据给出以源端为基准的订正 SQL，把结论变成可执行的差异清单。
退得回。回退通道要在切换动作里启动，而不是发现问题时再搭。OMS 第七步"启动反向增量"把目标端变更实时回流源端，但有前置条件：多表汇聚或多套 schema 映射到同一 schema 时不支持反向增量。回退能力在方案阶段就被拓扑决定了，切换当天再确认往往来不及；平安人寿的三阶段迁移把写切换与反向同步通道放在同一阶段，结构相同。
收得掉。回退窗口要有终点。Stripe 把删除源端数据放在最后一步，确认完成才 drop；OBUS 在切换后观察半小时，达标则关闭反向增量同步，不达标则反向切换流量。两个方向都有明确动作，回退窗口才会关闭；缺少这一步，"随时能回"会一直占用源端资源。
三、窗口预算：四段时间与一个上限
停写窗口不是估计值，而是四段时间之和：剩余追平、一致性校验、对象与权限处理、回退预留。
图 2：四段之和构成停写窗口；上限取自业务可容忍的中断或应用的重试预算。
剩余追平取决于停写瞬间的位点差与通道速率。大事务、DDL、批量任务单位时间产生的日志量远超日常写入，会把这一段拉长；通道速率低于写入速率时，位点差不会自行收敛，提前停写只是把等待挪到窗口内的另一处。可行的做法是更早把增量压到接近实时，让停写时的位点差足够小。
一致性校验的耗时由口径决定：全量逐行比对与分片校验和是两笔预算，抽样明细更便宜，结论强度也更弱。校验还要控制对源端的压力，常见做法是在只读副本或快照上执行。
对象与权限处理常被当成零碎工作，实际有依赖顺序。OMS 单列这一步：删除迁移期间附加的列与索引、补充被忽略的约束、确认 Trigger 与 Sequence 已手工迁移、确认源端触发器与外键已关闭。顺序不能颠倒——正向同步还在运行时，源端 DDL 会沿链路到达目标端，先删源端触发器，目标端同名对象会一起消失。
回退预留不是"留一点余量"，而是按回退序列实测的耗时：停写、锁定账号、等待反向追平、停止反向增量、校验、恢复触发器与外键、解锁、切换连接。这条序列若比窗口还长，说明窗口设计要调整，压缩预留并不会让它变短。
四段之和的上限来自业务侧：应用能容忍的中断时长，或它的重试预算。超限时只有两个方向——把动作移出窗口（提前完成对象处理、提前建好反向通道），或改变切换方式（先切读后切写、按域分批、灰度放量）。在窗口内继续压缩时间，通常只是把风险转移到操作速度上。
四、回退包含四类动作
回退不是"把连接串改回去"，它至少包含四类动作，每一类都有独立的验证对象。
通道。反向增量是否可用、是否已启动、延迟是否可观测。前面提到的拓扑限制在此生效：不支持反向增量的拓扑，回退只能靠重放或补偿，方案要在设计阶段写清楚。
数据。切换之后写入目标库的那部分数据，回退时归谁。两种处理：经反向通道回流源端，或在源端按同样的业务请求重放并核对结果；前者依赖通道，后者依赖可重放的请求记录。这一项决定了回退是"无损"还是"有损"，也决定了窗口能开多长。
对象与权限。开启反向增量会改变源端的对象状态，OBUS 文档写得很直接：MySQL 兼容模式下删除触发器、关闭外键检查，Oracle 兼容模式下禁用触发器和外键约束。反向切换时则有一步"解锁源端用户和对象"，把正向切换时锁定的用户、被禁用或删除的触发器与外键恢复回来；序列与自增值在两端可能已经分叉，也要单独核对。
路由。DNS、VIP、连接串、连接池重启、灰度名单与调用方通知。这一类的特点是动作很快，但生效时间不确定，缓存和长连接会让"已切换"与"实际生效"之间出现时间差。
四类动作合起来是一条与正向切换镜像的序列，演练要演练这条序列，而不是其中某一个动作。
五、演练能证明的范围
演练与正式切换之间有五处固定差异，决定结论能外推到什么程度：数据量不同，演练库常是生产数据的子集，校验与追平耗时偏短；并发分布不同，压测流量的构成、参数分布与到达节奏和真实请求不一致；变更约束不同，正式切换通常禁止 DDL，演练未必同样冻结；人员授权不同，停写与批准回切的权限在演练里常由一人兼任；时间压力不同，演练可以重来，正式窗口只有一次。
由此得到两条限制。不注入故障的演练只验证了正向路径，回退要单独演练：在切换后的观察期内按回退序列走一遍并记录耗时，或者在预发环境注入"校验不通过"，观察系统是否按预案停下。第一次演练的耗时不能直接当作正式窗口的依据，但它给出了各段的耗时结构和瓶颈位置，这已经足够修正预算。
演练记录建议固定四类内容：时间线、每步实测耗时、注入的故障与系统反应、决策与授权。这四类记录也是下一次变更的基线。
判据要写成可测的形式。“追平"写成"位点一致，且延迟不超过 15 秒并持续 5 分钟”，“性能正常"写成"P99 不超过基线的 1.2 倍，错误率不超过基线加 0.1 个百分点”（数值为示意）。不可测的判据在窗口压力下会退化成"看起来还行"，而这样的结论无法在事后被核对。
六、观察期里的业务证据
切换完成后有一段观察期。监控能回答系统是否正常，回答不了业务行为是否与切换前一致：同样的下单请求，在新库上返回的金额、状态、可用额度是否相同，日志和指标都不会直接给出答案。
一种可执行的做法是把比较前置成基线：切换前在旧库录制一段真实流量，含入口请求与依赖调用；切换后在目标库的隔离环境回放同一批请求，比对响应与依赖调用，含语句、参数和影响行数，产出差异清单、失败定位与可复用的样本。
以 Softprobe 为例，它承担的就是这一段：录制阶段保存请求与响应，回放阶段把数据库依赖配置为真实调用、非迁移依赖按录制结果返回，逐项给出响应与依赖调用差异。它不编排切换，不执行回退，也不判断业务规则是否正确；一致性结论仍来自校验任务，回退决策仍由变更负责人作出。接入前需确认目标库驱动与回放环境的适配，回放环境要能重置数据或回滚快照，因为回放会写库。
这段证据有两个用途：作为观察期"业务行为未变"的支撑，以及下一次发布的回归基线。
七、判据表
把上面的讨论收敛成一张表，每一项都能在切换当天取数、在事后被复核。
| 属性 | 判据（示例） | 证据 | 时点 |
|---|---|---|---|
| 停得住 | 旧库写入为 0；写权限已撤销并用测试账号验证 | 源端会话数、写入计数、权限变更记录 | 停写后 5 分钟内 |
| 追得平 | 位点一致；延迟不超过阈值并持续一段时间 | 同步位点、延迟曲线 | 停写后、校验前 |
| 对得上 | 约定口径的校验通过；差异为 0 或已逐条归因 | 校验报告、差异清单、订正 SQL | 校验完成后 |
| 退得回 | 反向通道运行中且延迟可观测；回切序列已演练 | 通道状态、演练记录、耗时实测 | 切换前 |
| 收得掉 | 观察期指标达标后执行关闭；源端保留到确认时点 | 关闭记录、保留期设置、源端释放记录 | 观察期结束时 |
切换的结论，是这五行记录加上各自的阈值和时点。"切换成功"是这些记录的结果，不是判据本身。回退同理：它是一条演练过的序列，序列中任何一步缺少证据，回退的可行性就无法在切换前被确认。
素材说明：Stripe 的迁移流程、版本令牌、时间点快照校验与"关键阶段短于一次主库故障切换"的表述，来自 Stripe Engineering Blog《How Stripe’s document databases supported 99.999% uptime with zero-downtime data migrations》，2024 年 6 月 6 日（https://stripe.com/blog/how-stripes-document-databases-supported-99.999-uptime-with-zero-downtime-data-migrations ）。OMS 正向切换八个步骤、15 秒延迟阈值、对象处理与反向增量的拓扑限制，来自 OceanBase 文档《使用 OMS 迁移 MySQL 数据到 OceanBase 数据库》（https://www.oceanbase.com/docs/community-observer-cn-10000000001878970 ）。OBUS 观察半小时、关闭反向增量同步与反向切换流量的步骤，来自 OceanBase 文档《升级流程》（https://www.oceanbase.com/docs/common-obus-1000000005151050 ）。平安人寿三阶段迁移与反向同步通道，引自老鱼笔记 2025 年 11 月 27 日整理的公开报道（https://www.modb.pro/db/1993858969082339328 ）。案例的规模与阈值仅属于原系统；本文的属性划分、预算结构与判据表为本文归纳，不表示任何产品或项目已按此实施。
本文由Softprobe 质量工程实验室原创发布，欢迎关注获取更多前沿技术实践。
