大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
数据库迁移最大的挑战是什么？
中国信通院《数据库发展白皮书》指出，核心系统的数据库迁移面临三大难题：停机窗口长、数据一致性难保证、故障后缺乏回退手段。传统模式是“停机 → 全量迁移 → 停机 → 增量追平 → 切换”，两次停机加在一起，对于7×24小时运行的核心系统来说，窗口根本不够用。
双轨并行要解决的，正是这三个问题。
一、双轨并行的核心思路
双轨并行的本质是让新旧两套数据库系统同时运行。旧系统继续承载业务流量，新系统作为热备实时接收数据。验证充分后，业务流量逐步切换；如果新系统出现问题，流量可以快速切回旧系统。
这套思路听起来简单，但落地需要三个核心技术能力。
第一，增量数据的实时捕获。 全量迁移完成后，旧系统仍在产生新数据。这些增量变更必须被实时捕获并同步到新系统。捕获的粒度和速度，直接决定双轨并行期间的数据一致性。
第二，双向同步与快速回切。 业务切换到新系统后，新系统产生的数据需要反向同步回旧系统。这样旧系统作为热备节点始终与生产系统保持一致，一旦新系统出现异常，可以立即切回。
第三，全周期的数据一致性校验。 双轨运行期间，两端数据必须持续保持一致。不能依赖人工抽查，需要系统自动校验和修复。
三个能力环环相扣：增量捕获是基础，双向同步是保障，一致性校验是底线。
二、增量同步的技术原理
增量同步的核心是日志解析。数据库的所有变更操作都会记录在物理日志中（Oracle的Redo Log、MySQL的Binlog、KES的WAL）。增量同步工具需要读取这些日志，解析出具体的行级变更，再封装成统一的格式发送到目标端。
这个过程中有几个关键的技术点：
SCN定位。 全量迁移结束时，源端数据库有一个精确的SCN（System Change Number）。增量同步必须从这个SCN开始捕获，才能保证不漏不重。
日志解析与格式统一。 不同数据库的日志格式完全不同。Oracle的Redo Log是物理日志，MySQL的Binlog是逻辑日志，KES的WAL是物理逻辑混合。同步工具需要屏蔽这些差异，输出统一的中间格式。
事务边界保持。 增量同步必须遵循源端事务的提交顺序，保证事务的完整性。如果一个事务包含多条DML操作，同步时不能只同步其中一部分。
断点续传。 同步过程中如果出现网络中断或目标端故障，恢复后需要从断点继续，不能从头再来。
三、双向同步与回切机制
双轨并行的核心价值在于“可回退”。传统迁移是单向不可逆的——切过去就切不回来了。双轨并行通过反向同步链路保留了回退能力。
正向同步阶段：旧系统为主库，新系统为备库。旧系统的所有变更通过增量同步发送到新系统。
反向同步阶段：业务切换到新系统后，同步工具自动建立反向链路。新系统的变更实时回传旧系统，旧系统作为热备持续接收更新。
回切流程：一旦新系统出现异常，流量在分钟级内切回旧系统。由于旧系统一直通过反向同步保持与新系统一致，回切时数据完整，业务快速恢复。
这个机制的关键在于：反向链路的建立必须是自动的，不能依赖人工配置；切换过程必须对应用透明，不需要修改连接串或重启服务。
四、全周期一致性校验
双轨并行最核心的保障机制是数据一致性校验。校验分三个阶段：
阶段一：存量数据校验。 全量迁移完成后，在线比对源库与目标库的存量数据。校验工具通过快照查询技术，在不影响业务读写的情况下对两端数据做哈希比对。如果发现差异，生成修复脚本。
阶段二：增量数据校验。 在实时同步过程中，并行启动增量校验线程，对比日志中的变更记录与目标库的实际入库结果。增量校验关注的是同步过程中是否有丢失或重复。
阶段三：切换前一致性确认。 业务切换之前，再次执行全量校验确认两端数据完全一致。如果发现差异，自动修复后再次校验，直到一致为止。
传统的全量校验需要停机执行，75分钟才能完成一次。在线校验方案将这个过程压缩到零停机——业务不受影响，校验在后台完成。
五、技术实现
KFS是双轨并行方案的典型实现。它的核心机制是：通过安装轻量级Agent直接读取源端数据库的物理日志文件，解析日志中的行级变更数据，封装为KUFL（Kingbase Unified Format Log）格式，实时同步至目标端。
技术特点：
不侵入数据库内核：通过日志解析而非触发器或中间表，对源库性能影响小
遵循事务提交顺序：保证数据完整性，不会出现事务部分同步的问题
支持断点续传：同步中断后可从断点恢复，不需要重新全量
亚秒级同步延迟：通过SCN精确定位起始点，实现低延迟实时同步
KFS的实际项目中，某金融机构核心交易系统拥有超过3TB数据，包含500余张关键业务表及百余个复杂存储过程。业务部门要求核心系统全年99.99%可用性，计划内停机窗口不得超过分钟级。
采用KDMS（结构迁移）+ KDTS（全量迁移）+ KFS（增量同步）工具链，构建无中间库的双轨并行架构。全量迁移期间业务仍运行在源端，全量完成后KFS接管增量同步。双轨并行期间，部分只读流量引导至新系统验证。验证通过后流量切换至新系统，KFS自动反转数据流向。
结果：3TB数据在业务不停机的情况下完成平滑切换，增量同步延迟稳定在亚秒级，无中间库、低延迟同步方案验证可行。
六、适用场景与选型建议
适合双轨并行的场景：
核心交易系统，停机窗口在分钟级以内
数据量大（TB级以上），无法在单次停机窗口内完成迁移
对数据一致性要求极高，RPO必须为零
需要保留回退能力，迁移风险必须可控
选型关键指标：
增量同步延迟是否达到亚秒级
是否支持双向同步与自动反向切换
一致性校验是否支持在线执行与自动修复
是否支持复杂对象（存储过程、序列、视图）的无损映射
是否适配国产芯片和操作系统
七、小结
双轨并行的核心价值在于：把迁移的“一次性高风险操作”拆解为“可验证、可回退的渐进过程” 。通过增量同步、双向切换和在线校验，迁移期间业务零中断，出问题能分钟级回退。对于核心系统的数据库迁移，这套方案正在成为标配。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
