数据迁移切换流程图怎么画？停写、校验、切换与回退

数据迁移切换流程图应从“哪套系统还能写入”画起，而不是从“复制数据”画起。一个可执行的主线是：确定旧库与新库的责任边界 → 控制写入并追平增量 → 校验关键数据和应用行为 → 作出切换判断 → 切流并观察；任一门槛未过，停在原系统或进入事先设计的回退路径。最危险的省略，是新系统已经接收新写入，却把回退画成一根简单的“切回旧库”箭头。

下面用订单系统从旧库迁到新库的情境，说明如何画这张决策图。Boardmix 的 在线流程图画布适合让开发、运维、业务负责人共同核对步骤与接手人；真正的数据复制、流量切换和回退仍由实际系统和变更流程执行，画布本身不会替你运行迁移。

1. 开图前确定系统边界与回退窗口

先写清迁移对象：订单主表、明细表、付款状态、附件索引和需要一起变更的应用入口；再标出谁有权批准切换，以及哪套库在各阶段是唯一的写入源。若应用有后台任务、回调或人工补单，不能只停前台下单页面就称“停写完成”。这些写入源要么被暂时暂停，要么进入有序队列，并明确恢复办法。

回退条件也应在切换前决定：什么样的校验失败必须停止、切换后观察哪些关键业务动作、谁宣布回退、回到旧系统时怎样处理新库已产生的订单。若这些问题没有答案，流程图的“回退”分支还不能作为可执行步骤。

2. 主线画成六段，并给每段写交付证据

1. 停写或控写。列出会写订单的全部入口，记录暂停、排队或限制写入后的状态和负责人。不要在图上只写“业务暂停”。
2. 追平增量。确认最后一批变更已进入新库，记录用于判断进度的水位或任务状态。复制任务显示“运行中”不等于目标数据已追平。
3. 双侧校验。比较订单总数、关键状态分布、最近变更记录与业务约束；对异常样本保留编号和处理结论。只比总行数，可能漏掉状态或关联关系错误。
4. 切换判断。开发、运维和业务负责人依据事先约定的门槛共同确认“继续/暂缓”。关键差异未解释、回退路径未准备好，就走“暂缓”分支。
5. 切流与冒烟检查。按变更单调整应用连接或流量路由后，检查读写路径、下单、查询和必要的外部回调；保留切换时间点与执行人。
6. 观察并收口。持续看错误、延迟、订单状态和客户反馈。观察期结束且异常有结论，再解除写入限制并完成交接。

3. 把“校验通过”拆成可判定条件

校验框内不要只放一个绿色对勾。至少区分结构、数据和业务三层：表结构与约束是否符合应用预期；主键数量、状态分布和关联记录是否一致；用户能否完成订单创建、查询和后续状态流转。对历史脏数据或源库原有缺陷，要单独列出已知差异，避免把它们与迁移过程造成的新差异混为一谈。

校验方法必须与实际架构匹配。例如 AWS 的迁移实践文档建议在迁移过程中使用数据校验，并监控复制任务和表级指标；这不能代替你对订单业务约束的检查。具体平台的能力与可用指标以所用工具为准。

4. 切换后的回退分支为什么不能省略新写入

切换前旧库通常仍是主要写入源；切换后新库可能开始接收新订单。此时旧库已经不再包含全部最新数据，直接把应用连接切回旧库，可能让新订单“消失”。在图上应先经过一个判断：新库是否已有必须保留的写入？若没有，可按预案恢复原路由并核查；若有，要先执行事先设计的反向同步、暂停写入并对账，或采用其他经过验证的恢复方案，再决定怎样恢复服务。

这不是某一种数据库的通用按钮。AWS 的切换指导也提醒：切换后产生的新交易会让回退涉及把数据从新环境带回旧环境。图中应标明这条数据处理路径、负责人和核对结果，而不是画一根没有条件的回箭头。

5. 用一次桌面演练检查断点

安排每个岗位顺着图回答四个问题：“现在谁能写订单？”“若校验失败，谁阻止切换？”“切流后发现异常，谁决定回退？”“新订单如何保全？”任何一步没有唯一责任人或可读取的证据，就把它标成待定项并在变更前补齐。一次演练的价值，不在于把箭头走完，而在于在真正切流前暴露说不清的责任与数据去向。

正式变更时，将流程图与变更单、校验结果、监控看板和事件记录相互关联。流程图保留判断结构，实时执行状态留在对应系统；版本发生变化时，先更新流程图中的条件和责任，再使用新版本。

常见问题

全量复制完成后能立刻切换吗？

不能只看全量任务结束。仍需确认后续增量、关键数据校验、应用读写路径和回退准备是否通过。

停写一定要关闭整个系统吗？

不一定。可以按架构选择暂停特定写入入口或排队处理，但必须知道所有写入来源、积压去向和恢复条件；不能仅凭前台页面不可提交就认定停写完成。

已经切流，旧库还能直接作为回退目标吗？

要看新库是否产生了新写入以及预案如何保留它们。没有数据回流或对账方案时，简单切回可能造成记录缺失。