1. 信创迁移丢数不是玄学是方法论缺位先说结论信创环境下的数据库迁移绝大多数丢数事故并不是迁移工具本身有多烂而是整个项目从一开始就把迁移理解成了搬运。数据搬过去之后业务一上线发现账对不上、统计少一条、下游报表数据漂移这时候才回头查问题成本已经是灾难级别。我自己经历过几个信创迁移项目包括 Oracle 迁达梦、Oracle 迁人大金仓、MySQL 迁 openGauss以及 SQL Server 迁集中式国产库的场景。老实讲工具层面各家虽有差异但核心问题从来不在能不能搬而在怎么验证搬得对不对、切换时怎么保证不停业务、出问题怎么快速回退。这三个问题如果没有在项目启动前就想清楚那丢数基本是迟早的事。这篇文章我把整套方法论摊开讲包括迁移前要做什么评估、全量和增量阶段各自的坑、切换前的验证手段、平滑切换的步骤设计以及我踩过之后才明白的避坑经验。适合正在做信创改造、数据库国产化替换的 DBA、架构师、项目经理和技术负责人参考。里面每个环节我都会说清楚为什么这么做而不是只丢给你一套流程。2. 迁移丢数的真实原因先分清死丢和活丢要解决丢数问题先得搞清楚丢数到底发生在哪个环节。我把实际项目中遇到的丢数分为两类一类叫死丢一类叫活丢。2.1 死丢数据压根儿没进目标库死丢是最容易定位也最容易被忽视的一类。常见场景包括全量导出时使用了错误的过滤条件比如只导了部分分区、部分 schema源库存在视图、序列、存储过程、触发器全量工具只迁移了表数据这些对象没有同步过去字符集不一致导致数据在导入时报错而工具默认跳过错误行大字段CLOB/BLOB在导出时被截断目标端写入失败但工具没有提示自增列、默认值、约束没有迁移导致目标端插入失败后静默回滚。死丢的特点是全量阶段就能发现只要你做一次严格的行数字段级比对校验。但如果项目组只做了行数比对那视图、序列、存储过程这类看不见的数据丢了要等业务调用时才会暴露。这个我在后面校验方式一节会详细说。2.2 活丢迁移完成时数据是齐的业务一跑又不对了活丢比死丢隐蔽得多也是数据库迁移总丢数这个现象最核心的元凶。典型场景全量迁移完成增量同步追平切换窗口内业务停写原库和目标库数据完全一致。但切换后跑了一天业务反馈少数据。这类问题的根源通常在于增量同步工具捕捉的是源库的 redo/binglog 日志但源库存在一些不写日志的操作比如 Oracle 的 nologging 表、MySQL 的 UPDATE 不走 binlog 的特殊配置应用层存在双写逻辑切换前一部分流量还在写老库另一部分已经切到新库两边数据出现交叉增量同步无法覆盖定时任务、批处理在切换窗口外运行产生了一波不在计划内的数据变更源库存在跨库事务或分布式事务增量工具只订阅了其中一个库的日志另一个库的变更没有同步。活丢的排查难度比死丢高一个量级因为它往往不表现为目标库比源库少数据而表现为目标库的数据逻辑上不完整。比如订单表有记录但订单明细表缺行或者流水表有主记录但扩展表没有对应记录。要防住活丢不能只靠工具得靠切换流程设计——这就是零故障平滑切换的核心逻辑不追求在某一时刻数据完全一致而是追求在切换点之后所有数据变更的起点都位于新库。3. 迁移前要做的事先当质检员再当搬运工很多人以为迁移项目的第一步是选工具、搭环境、跑全量。错了。第一步是盘清楚你手里到底有什么货。3.1 数据资产盘点不止是表清单我的习惯是在项目启动前做一次完整的存量对象盘点产出清单包括对象类型盘点要点表数量、行数、数据量、分区情况、是否含大字段索引数量、类型普通/唯一/位图/函数索引、是否需要迁移约束主键、外键、唯一约束、Check约束视图数量、定义中是否包含只存在于源库的特性函数存储过程/函数/包数量、依赖关系、涉及的系统表序列/自增列当前值、步长、缓存设置触发器数量、作用表、是否会在增量阶段造成重复执行定时任务/Job是否需要在切换后重建用户/权限账号数量、权限粒度、与应用的绑定关系每项背后都对应一个迁移后可能丢的东西。比如序列很多国产库支持创建序列但迁移工具默认不导序列的当前值结果业务一插入主键就冲突。再比如触发器如果源库的触发器在写入时自动更新某个审计字段迁到目标库后触发器没建审计字段全是空的——这不是丢数是什么盘点的产出不只是一个 Excel而是一份迁移对象责任清单每类对象要指定负责人、迁移方式、验证方式。这一步做到位后面至少能避开一半的坑。3.2 异构兼容性评估别等导入报错才后悔信创迁移绝大多数是异构迁移Oracle/DB2/SQL Server 迁到达梦、金仓、GaussDB、openGauss 之类。异构带来的问题不是能不能导入而是导入之后语义是否一致。举个最常见的例子Oracle 的NUMBER类型没有长度限制而国产库有的用NUMBER(38)、有的用DECIMAL变体。如果源表某列存了超过 38 位精度的数字比如某些流水号迁移时工具可能截断或报错。这种问题在盘点阶段就该识别出来提前与业务方确认精度要求而不是等到全量阶段被刷屏的报错淹没。再比如 Oracle 的DATE类型包含时分秒而 MySQL 系的DATE只有日期TIMESTAMP的精度、时区处理、空字符串与 NULL 的区别……这些细节每一条都可能造成看起来数据没少实际上业务逻辑错乱。我的建议是在选型阶段就准备一份异构差异清单把源库和目标库在数据类型、SQL语法、函数、排序规则、事务隔离级别、锁机制上的差异全部列出来逐条确认应用侧能否适配。这个清单至少要覆盖应用涉及到的 SQL 语句类型而不是只盯着数据字典。3.3 迁移预案31原则预案是迁移的保险绳你没出事的时候觉得它多余出事了才知道命是它给的。我总结为31全量失败预案全量迁移中途失败已导入的数据如何处理清空重导还是断点续传增量延迟预案增量追不上业务写入速度时是扩容同步通道还是提前切读流量切换失败预案切换后验证不通过如何快速回退到原库需要停业务多久。1是指决策预案——即出现问题时谁能拍板、按什么标准拍板。很多项目死在预案有但没人敢按预案执行关键切换点迟疑 20 分钟业务就多停 20 分钟。4. 全量迁移的正确姿势别让工具替你思考全量迁移看起来最简单源库导、目标库导、跑完收工。但恰恰是看起来简单这一步埋下了最多的暗雷。4.1 全量导出方式怎么选常见的全量方式有三种方式一原生工具导出。比如 Oracle 的 expdp/impdp、MySQL 的 mysqldump、SQL Server 的 BCP。优点是成熟稳定、对源库特性支持最全缺点是异构迁移时目标库可能不认这些格式需要中间转换。方式二迁移工具直连抽取。比如达梦的 DTS、金仓的 Kettle 插件、各类商业迁移平台。优点是可视化配置、支持断点续传、能自动建表缺点是对复杂对象分区、高级队列、物化视图支持不一且工具的自动往往意味着按工具理解的方式处理不一定符合你的业务语义。方式三ETL 工具Kettle/DataX/Informatica 等。优点是灵活可控能写转换逻辑缺点是性能通常低于原生工具大批量数据迁移耗时较长。我的选择策略是表结构简单、数据量大的表用工具直连或 ETL 分片抽取表结构复杂、含特殊类型的表单独写脚本处理视图、存储过程、函数这类对象一律手工迁移不依赖工具的自动转换。不要幻想一个工具能完美处理所有对象把核心对象的迁移控制在自己手里才谈得上零故障。4.2 并行度和分片全量迁移的性能开关全量迁移经常遇到的问题是太慢。慢的原因九成出在两点单线程抽取、无分片写入。正确做法是数据抽取按主键或时间字段做分片每个分片一个线程分片大小建议控制在 10 万到 50 万行之间太大则单线程耗时过长、失败重试成本高太小则线程调度开销大整体性能上不去目标端写入采用批量提交每批 1000~5000 行视目标库性能调优写操作关闭目标表的约束和索引导入完成后再重建——注意这一步要谨慎必须先确认应用在迁移窗口内不会访问目标库否则约束缺失会造成数据质量问题。还有一个经验值目标库的 redo 日志、归档日志空间要提前放大 2 倍以上。全量导入会产生大量日志空间不足时数据库可能直接挂起这可是我亲身踩过的坑。4.3 全量后的校验三个层级缺一不可很多团队的全量校验就一句话行数对上了没问题。 我见过太多行数一致但数据仍有差异的案例所以必须强调只对行数等于没校验。我习惯做三层校验第一层行数校验。每张表行数对齐这是底线但只是底线。第二层特征校验。对关键表做聚合比对比如按日期分组统计记录数、求和关键金额字段、统计 distinct 值数量。这一步能发现行数一样但内容漂移的问题。第三层抽样明文字段比对。取每张表一定比例一般 1%~5%数据量大时按表取阈值的记录逐字段比对源端和目标端的值。注意比对时要做类型归一化处理比如源端空字符串与目标端 NULL 的统一判断。我常用一个简单的 SQL 手段做特征校验在源库和目标库分别跑同一组统计 SQL把结果导出成 CSV 再用 diff 比对。虽然没有专门的校验工具那么炫但胜在可控、可追溯出了问题也知道是哪条 SQL 发现的。5. 增量同步的真相追平不等于一致全量迁移完成之后进入增量同步阶段。目标是在业务切换之前把源库的在线变更持续复制到目标库。这个阶段的坑比全量更隐蔽因为工具显示同步延迟 0 秒并不代表数据真实一致。5.1 增量同步工具的机制差异常见的增量同步机制有三种基于日志解析Oracle 用 LogMiner 或第三方工具解析 redo logMySQL 用 binlogSQL Server 用 CDC 或事务日志。优点是对源库影响小缺点是对日志格式、版本兼容性敏感遇到特殊操作如 DDL、分区维护可能解析失败。基于触发器/影子表在源库建触发器记录变更。优点是通用性强能支持几乎所有数据库缺点是对源库性能影响大生产环境慎用。基于时间戳/增量字段轮询应用在源表加 update_time 字段工具定期扫描变更记录。优点是简单直接缺点是无法捕获删除操作、无法捕获没有时间戳的变更而且轮询间隔内的数据可能被跳过。信创项目里最常用的还是日志解析。但日志解析有个绕不开的问题不同版本的源库日志格式有差异工具厂商的适配速度跟不上数据库版本更新的速度。选工具之前一定要拿你实际使用的数据库小版本做一次增量性能压测不要只看厂商宣传支持某个大版本。5.2 增量同步追平之后还要做静态一致性校验当工具显示增量延迟为 0 时我从来不会直接进入切换。我会再做一次静态一致性校验具体做法是在业务低峰期短暂比如 5 分钟暂停源库的写操作或者暂停应用写入记录暂停开始时间 T0在源库做一次基于快照的统计对比行数、聚合值在同一时间点在目标库做同样的统计对比两边结果一致才算静态一致。这一步的价值在于日志解析类的增量工具本质上是异步复制工具显示 0 延迟只能说明日志已经消费到某个位置不能证明目标库已提交的事务和源库完全对齐。跨库事务、分布式事务、日志乱序提交的情况下工具显示 0 延迟但实际两边差着几个事务这种事真的发生过。5.3 增量阶段最大的隐藏坑DDL 和特殊操作增量同步工具最怕的往往不是 DML而是 DDL。源库执行了一条ALTER TABLE ADD COLUMN工具可能直接报错停止更麻烦的是某些工具会同一张表执行TRUNCATE而工具并没有把 truncate 翻译到目标库——结果源表数据被清空目标表还留着旧数据两边彻底不一致。还有一类特殊操作Oracle 的MERGE、MySQL 的REPLACE INTO、数据库的LOAD DATA批量导入。这些操作在日志里表现为混合 DML如果增量工具实现不严谨很容易出现数据不一致。我的建议是在增量同步阶段任何涉及 DDL 和批量操作的需求必须走变更审批流程提前通知迁移团队由人工确认工具能正确处理后再执行。不要指望工具能自动 handle 一切。6. 零故障平滑切换关键在于切断而不是复制平滑切换是迁移体系里最容易被误读的概念。很多人以为平滑切换等于不需要停业务。真正的平滑切换指的是切换过程中用户无感知或感知极短而不是业务完全不中断——完全不停业务的切换在异构数据库场景下几乎不可能因为切换意味着流量从一个数据源切到另一个数据源数据源切换本身需要时间。这里必须把话说透做切换方案时目标不是0 停机而是可接受的极短停机 无数据丢失 可快速回退。6.1 切换窗口怎么定切换窗口的长度取决于三件事最终一致性校验要多久、应用停写要多久、流量切换要多久。以一个中型系统为例几百张表、核心表千万级数据我的经验是阶段耗时估算最终一致性校验20~40 分钟应用停写/停服务5~10 分钟切换流量路由1~5 分钟目标库功能冒烟测试10~30 分钟合计40~85 分钟这个时长要在业务低谷期完成并且提前与业务方确认可接受范围。很多项目失败是因为切换窗口定得太紧比如只给 30 分钟最终一致性校验本身就要 40 分钟必然导致仓促切换、跳过校验最后数据出问题。6.2 切换五步法我把切换过程拆成五步每一步的执行者和验证标准都提前明确第一步冻结写流量。应用层做只读切换或直接停止写操作入口。这一步不是关数据库而是让应用不再产生新的写事务避免增量工具出现追不完的尾巴。第二步追平增量并停掉增量同步。等增量工具消费完全部日志记录停同步时刻的日志位点。这个位点要留存它是回退时判断哪些数据是新库独有的的依据。第三步最终静态一致性校验。同一个时间点源库和目标库做全表行数校验 关键表特征校验。这一步必须通过才能继续不通过直接走回退预案。第四步切换应用读写路由。修改应用数据源配置、负载均衡规则、或中间件路由把流量切到目标库。注意顺序先切只读流量验证目标库读性能正常后再切写流量。第五步目标库冒烟验证。应用团队执行核心功能用例重点覆盖登录、查询、新增、编辑、删除等基础链路。同时监控目标库的连接数、慢 SQL、锁等待等指标。6.3 回退机制不是为了失败设计而是为了敢切换设计我们常说不要把回退当备胎但现实中很多团队恰恰是因为没有回退方案才在切换出问题时死扛最终造成更长时间的停机。回退方案设计的原则是在切换后的一定时间内一般 24~72 小时如果发现问题能够快速切回原库且不丢失切换后产生的数据。实现方式有两种一种是双写回退切换后的一段时间内应用同时写新库并异步复制回老库老库作为影子库保留。这样一旦需要回退老库只有新库的增量数据本地的原数据仍然完整。另一种是日志补偿回退切换时保留增量同步的位点切换后增量工具反过来把新库产生的日志同步回原库。这个方案对工具要求更高一般商业迁移工具支持。我个人强烈建议采用双写回退。虽然双写会对性能有一点影响但切换后的头 48 小时本来就是高风险的监控期用一点性能换一个完整的后悔药很划算。6.4 切换后 48 小时别急着庆祝切换完成不是项目结束而是最容易出问题的阶段才刚刚开始。切换后 48 小时内按我这边的经验至少要盯这几项目标库连接数和慢 SQL 曲线与切换前的基线对比数据增长量是否正常是否出现批量插入异常应用报错日志中与数据库相关的错误码数量增量工具停掉之后有没有遗留的同步进程还在写目标库这个坑真的存在过——切换时停了同步工具但某个子进程没被 kill 继续写数据导致最终校验被打乱定时任务、批处理作业是否按预期在目标库上运行。这 48 小时里每天至少要跑一次全表行数对比和特征校验直到确认目标库的数据增长逻辑与业务模型匹配才真正算切换成功。7. 避坑清单每个坑都是学费换来的最后把这个项目里最值得分享的避坑经验按条列出来每条都是真实场景里换来的教训。7.1 日志解析工具选型的坑选增量同步工具时很多人只问支持 Oracle 吗支持 MySQL 吗而不问**支持我用的这个版本吗支持这个版本下的 RAC/主备架构吗DDL 操作能正确识别吗大事务会不会 OOM主备切换后能自动恢复吗**。我遇到过一次真实事故Oracle RAC 环境下增量工具连接的是节点 A节点 A 发生故障后连接漂移到节点 B但工具的日志解析位点没有正确切换导致后续增量数据全部丢失。这个坑在测试环境根本不会暴露因为测试环境没人做节点故障演练。所以我的建议是增量工具选型时必须包含一场故障演练——主备切换、节点宕机、网络闪断每个场景都要验证工具能否自动恢复且不丢数据。7.2 校验工作不能只依赖工具商业迁移工具大多自带有校验功能但我强烈建议核心数据表不要只信工具自带校验。原因很简单工具校验通常只做行数唯一键比对而信创迁移最容易出的问题恰好是字段级差异。我的做法是核心表交易、账务、用户等必须做明文字段抽样比对非核心表做特征校验工具的自带校验只作为辅助手段。这个工作量看起来大但值得——你总不想在业务上线一周后才发现某张表的时间字段被从北京时间悄悄变成了UTC 时间。7.3 权限和账号迁移别留死角数据库迁移时用户权限经常被忽略。虽然丢数这个字眼一般指数据但账号和权限丢了同样会造成应用连接异常业务侧表现出来就是查不到数据没权限报错。这里有三个容易踩的坑应用连接数据库使用的账号密码可能在源库和目标库不一致切换时应用连不上源库的 role/权限模型与目标库不完全兼容迁移后权限丢失或权限失效目标库的审计开关、密码策略与源库不一致导致应用侧行为变化比如密码过期策略不同切换后几天突然大量连接失败。信创产品的目录里很多都有适配认证但认证只说明产品能跑通基础功能不代表你手上的数据库版本、应用框架、中间件的组合没有问题。该做的兼容性测试、压测、演练一样都不能少。7.4 人月不等于熟练度演练是最好的老师最后说一个非技术层面的坑。信创迁移项目通常时间紧、任务重很多团队把大部分时间花在搭建环境和执行迁移上留给全链路演练的时间只有几天甚至一天。我的经验恰恰相反正式切换前的演练占整个项目时间的比例不应低于 30%。而且演练不能只是把流程走一遍必须包含故障注入——比如演练到一半人为制造增量延迟、演练时故意破坏某张表的校验看看团队能不能按预案正确处理。没有经过故障演练的切换预案本质上是一纸空文。你在正式切换时遇到的每个意外几乎都能在演练中提前暴露——前提是你真的演练了。8. 写在最后的个人体会做信创数据库迁移这几年我有一个越来越强烈的感受丢数问题从来不是一个技术工具问题而是一个工程管理问题。工具能帮你搬运数据能帮你解析日志能帮你同步增量但它不能替代你做盘点、做校验、做预案、做决策。真正决定迁移能否零故障平滑切换的是项目团队对数据资产的掌握程度、对异构差异的识别能力、对切换流程的把控能力以及面对故障时敢不敢按预案果断决策的勇气。工具选型顶多占三成权重剩下七成是流程、人和方法论。如果你正准备启动一个信创数据库迁移项目我建议你把本文讲到的盘点表、三层校验、切换五步法、双写回退、故障演练这五件事提前写进项目计划里。每一件看上去都增加了工作量但当你在凌晨两点面对切换验证数据不一致的告警时你会感激这些提前布置好的保险丝。最后分享一个小技巧正式切换前一周把核心表清单打印出来贴在作战室里每天更新校验结果。这个土办法看起来不起眼但它能让每个参与切换的人都对哪些表是核心、当前状态是什么保持清晰认知比任何大屏看板都管用。迁移这种高压场景最怕的不是技术问题而是团队对现状的认知不一致。