信创数据库迁移零故障切换：五段式方法论与丢数排查实战

做信创数据库迁移这几年我最怕听到的一句话是“数据怎么少了”信创数据库迁移表面上是把表和业务逻辑从老库搬到新库实际上是对一套还在持续运行的信息系统做不打断业务的“换心手术”。一旦把“迁移”理解成“搬运”丢数就是必然的。这篇文章不是讲某款具体产品的操作手册而是结合我实际参与过的多次国产数据库替换项目梳理出来的一套“迁移-追平-校验-切换-观察”方法论以及那些坑过我的细节。如果你正在做数据库国产化替代或者即将接手类似任务这篇内容应该能帮你少走很长一段弯路。1. 丢数问题的本质不是玄学是流程有洞接到报障说丢数第一反应通常是“工具坏了”。但我在现场查了太多次绝大多数丢数不是工具崩溃而是整个迁移流程在设计阶段就存在漏洞。数据库是一个永远在变的活系统不是Excel表格你复制一份就结束了。源库还在不停写入业务还在跑迁移工具读到的数据天然就是流动的。如果没有把“流动”这个因素设计进方案里丢数几乎是板上钉钉的事。1.1 三类高发丢数场景看看你有没有踩过第一类全量迁移和增量同步的衔接点对不上。全量导出用了某个时刻的快照但是增量同步的起始位点却从另一时刻开始结果中间一段时间产生的数据没有任何人接手。我见过最典型的案例是全量导出用了凌晨2点的快照但增量工具却因为配置错误从凌晨1点开始订阅等于有一个小时的数据黑洞还查不出来因为行数差异可能只有几千条散在几十张表里。第二类切换窗口内应用还在往源库写。理论上的标准流程是增量追平→停止源库写入→再次校验→切换连接。但实际上总有人觉得“差那几十秒没关系”或者应用侧连接池还没完全断掉。结果就是新库对外提供服务的那一瞬间还有一批写操作落到了老库上这批数据永远到不了新库。这种问题特别隐蔽因为事后看两边的行数一模一样就是个别表里最新一笔交易“穿越”了。第三类目标库的约束和源库不一样导致写入静默失败。比如源表没有唯一约束目标库为了“加强治理”加上了唯一索引。增量同步回放的时候重复键直接报错如果同步工具默认跳过错误那这条数据就默默丢了。等到业务查询时发现少了你连日志都不一定能对得上。所以迁移前的结构比对不只是比对字段类型那些约束、默认值、分区边界都要逐项核对。1.2 校验不完整丢数问题被“带上了线”还有相当一部分丢数是被不完整的校验手段漏过去的。很多团队验收只看“行数是否一致”这太不够用了。行数一致只说明记录数量相同不代表每一行的内容正确。可能源库某个字段是“北京”目标库变成“北京市”源库时间是“2024-01-01 08:00:00”目标库因为时区设置变成“2024-01-01 00:00:00”。这种差异用行数校验根本看不出来但切过去之后业务报表对不上照样是事故。更麻烦的是校验时点没有覆盖切换前最后一刻的数据。我见过一个项目迁移团队在下午三点做了全量校验两边一致然后继续做增量同步结果晚上七点切换时直接切了没有再校验。下午三点到七点之间产生的增量到底有没有完整同步完全靠猜。这就是典型的“验收时点”和“切换时点”脱节。正确做法是建立一条校验闭环全量校验、增量实时校验、切换前最终校验每一个环节都有明确的校验时点和日志记录。2. 零故障平滑切换的核心方法论所谓“零故障切换”不是指操作过程中没有任何风险而是指你把风险拆到了每一步每一步都有验证、有日志、有止损点做到即使出了意外也能快速恢复。我个人习惯把整个迁移过程拆成“五段式”基线迁移、增量追平、一致性校验、切换窗口、观察确认。每个阶段有明确的准入标准达不到标准就绝对不允许进入下一阶段。2.1 把切换当成一次有状态的服务发布做应用发布的时候我们很少直接“全量替换”通常会做灰度、做金丝雀。但很多搞数据库迁移的人却喜欢“一步到位”直接把连接串改成新库地址。这是典型的思维错位。应用无状态可以随便重启数据库是有状态的切换本质上是把“写入权”从一个实例交到另一个实例手里。你需要关注的不是“怎么切”而是“切完后那一个瞬间数据流是否已经对齐老库是否已经彻底停止接收写入”。所以我在设计切换方案时第一件事就是梳理应用和数据库之间的连接关系哪些服务已经改配置指向新库了哪些还在走旧连接中间有没有中间件做了一层路由。曾经有一个项目应用层配置已经全部切到新库但有个报表定时任务因为配置文件是独立打包的还在连老库跑了一整夜第二天报表数据和主库对不上也是一次不小的风波。2.2 五段式流程每步都有准入标准我习惯把流程写成像门禁一样每条标准都要打勾才允许进入下一步。第一阶段基线迁移。用全量工具把基础数据从源库搬到目标库。这阶段的准入门槛是导出快照完整、目标库无严重报错、大表和小表的行数比例合理。这里更像是“搭骨架”不要求业务完全对齐但要确保基础数据大体可靠。第二阶段增量追平。启动增量同步让目标库追上源库在基线之后产生的新变更。这阶段的准入门槛是同步延迟持续低于设定阈值比如10秒以内且延迟数值稳定不是一会儿0秒一会儿5分钟那种忽高忽低的状态。第三阶段一致性校验。在增量追平的基础上做内容级校验。这里我要求校验的结果必须生成一份报告列出哪些表完全一致、哪些表存在差异差异必须清零或者有明确的书面说明。第四阶段切换窗口。此时应用侧停止写入、源库只读再进行一次终极校验确认两库在同一个静止点上完全一致。然后修改连接策略让应用连到新库。这个窗口一般只有十几到几十分钟所有操作必须是脚本化的不能在窗口内手敲命令。第五阶段观察确认。切换后不是立刻验收而是继续观察新库的负载、慢SQL、锁等待、同步进程是否还在健康运行。我一般会盯住至少一个业务完整周期比如日切确保所有定时任务、批量任务都在新库上跑对了才敢宣告迁移完成。2.3 同步链路设计别只依赖一种方案增量同步的实现方式业内主要有两类一类是基于日志解析的CDC工具比如用数据库自带的数据同步组件或第三方同步中间件从逻辑日志/归档日志里读取变更事件另一类是基于应用层双写也就是应用在写老库的同时把同一条数据也写到新库。两种方案各有利弊。基于日志解析的优点是业务无侵入源库不需要改代码缺点是工具本身对数据库版本的兼容性要求很高尤其在国产数据库生态里很多自研组件还不成熟。双写方案优点是链路简单好理解缺点是对应用代码的侵入性太强需要所有写操作都过一次“分发器”一旦某些模块没走统一入口漏写的数据根本发现不了。我的建议是多条腿走路日志解析作为增量同步主链路同时在应用里对关键核心表做比对标记双保险。别把宝押在单一工具上尤其是那些刚上生产环境、还没经历过“跑批高并发”考验的同步组件。3. 核心环节实现迁移与校验细节如果说方法论是骨架那么迁移和校验的细节就是血肉。这一段我全部写成可以直接抄作业的实操要点都是我在项目上反复调整后总结出来的参数和步骤。3.1 全量迁移参数怎么调才能又稳又不拖垮源库全量迁移阶段不要在业务高峰期跑这是常识。但很多人不知道的是迁移工具本身的参数设置会直接影响源库的性能。一般来说批量提交的size选5000到10000行比较稳太小会导致网络往返次数太多太大则可能导致目标库事务过大产生锁竞争。并发度方面我建议从源库CPU核数的一半开始试再逐步往上加。比如源库是16核先设8个并发观察源库的CPU和IO等待如果都平稳再慢慢往上加。大表和小表的迁移顺序也有讲究。先迁主表、再迁子表可以避免外键约束检查带来的额外开销。如果目标库支持延迟约束校验可以先把约束禁用等数据全部迁完再开启并做一次全表校验速度会明显提升。但记得一定要在测试环境演练过“开启约束后的校验”否则生产上一边开约束一边扫全表数据库瞬间锁死也是有可能的。另外一个很多人忽略的点是快照一致性。如果你是直接从命令行导出一定把隔离级别设置成可重复读并且整个导出过程保持在同一个事务快照内。不要一个表一个表分别连上去导那样每张表拿到的快照时间点都不同表之间的数据可能互相矛盾。这也是我见过“单表行数都对但业务逻辑乱掉”的主要原因。3.2 增量同步追平怎么判断才算真正追平增量同步的追平不是看同步工具界面显示“延迟0秒”就算完。那个数字有时候是假的因为它只代表工具自身读取日志的进度不代表日志事件已经真正在目标库执行成功。我有一次排查问题界面显示延迟为0但目标库的某张表就是比源库少了好几万行后来发现是同步工具内部队列积压界面的进度取的是源端日志位置而不是目标端应用完成位置。我自己的判断标准有三条第一源库的日志位点比如LSN或SCN或日志序列号和目标库同步应用位点完全一致中间不再有新的日志产生第二目标库的关键表最后修改时间追平到当前时间附近且增量监控跑个几十秒没有新的差距拉大第三直接从源库随机抽几条最新写入的数据去目标库查马上查得到延迟在这个量级才算可以接受。如果延迟一直追不平先查目标库的慢SQL八成是目标库上某些执行计划走偏导致正常回放一条DML需要好几秒。这时候不要盲目加同步工具并发而是先看看目标库的统计信息是不是没收集索引是不是忘建了。有些国产数据库迁移完成后索引全部要重建如果省略了这一步增量同步的性能会差到让你怀疑人生。3.3 数据校验只数行数等于白干校验这件事我强烈建议分成三层来做。第一层是行数校验最基础但必须做它能快速发现问题巨大的表。第二层是内容校验用主键或唯一键分批对比两边的关键字段的值比如时间戳、金额、状态位逐字段比对或者对所有字段拼接后做一个hash摘要再比对。第三层是业务规则校验按业务对账口径编写SQL比如“今天的订单总额”“本月末库存量”两边跑出来应该完全一致。做内容校验的时候要特别注意大表的处理方式。不要一次性把整张表全部读进内存按主键范围切成若干个区间一段一段校验。切分区间时最好用整数主键如果没有整数主键可以用row_number窗口函数先打一个序号再切但这种方式大表上会非常慢尽量在迁移设计阶段就建议业务给核心表加上代理键。校验过程中如果发现差异不要急着改目标库数据先确定差异的类型是漏同步了还是字段值被转换错了还是主键冲突导致目标库更新错行。原因不同修复手段完全不同。4. 切换演练与回退方案宁可练到吐不能赌一把很多团队在迁移项目里忽视了演练总觉得“工具都验证过了切一下很快”。但真正的生产切换最怕的不是技术难题而是各种环节没有跑过的意外。演练的价值不是重复一遍流程而是把所有可能的故障都提前暴露在测试环境里。4.1 分级演练从纸面推演到全链路实战我习惯把演练分成三级。第一级是桌面推演把切换流程中的每一个操作步骤写成剧本包括谁来操作、谁来验证、卡在哪个环节需要停顿确认。推演时就要把“刀口向内”假设增量同步此时断开怎么办假设应用连接池没有完全释放怎么办假设切换后新库缓存未预热导致连接全部卡死怎么办这些假设写完之后每一条背后都必须有对应的处理动作而不是一句“到时候再看”。第二级是模拟演练在测试环境搭建一套和生产一致的源库与目标库导入生产脱敏数据按实际切换流程完整跑一遍记录每一步耗时。这一步的目的是校准切换窗口的时间预算。比如生产上全量数据和测试环境差不多但切换到新库后第一次启动应用会触发大量编译和缓存预热耗时长达20分钟这个时间如果不提前测算等你真正操作时才发现窗口根本不够就很被动。第三级是全链路带业务联调的演练应用服务也参与进来模拟真实用户的读写流量。这级演练能暴露很多数据库本身之外的问题比如中间件连接超时时间、应用侧对主键冲突的处理逻辑、消息队列在切换过程中的积压量。全链路演练至少做两次一次定在迁移项目中期一次定在生产切换前三天前一次找问题后一次验证问题是否修复完毕。4.2 回退方案怎么设计才算真靠谱回退方案的常见误区是“切完发现有问题把连接串改回来就行”。如果切换窗口内没有数据写入这个思路没问题一旦新库已经接受业务写入你再切回老库两边数据就分叉了回退等于丢了一部分新库产生的数据。所以回退方案必须提前定义清楚“在什么条件下允许直接回退”。我自己的经验是设置两个回退层级。第一层是切换窗口内的回退这个阶段新库尚未开放全部业务流量只有少数验证性请求。只要出现不可接受的问题直接执行回退脚本把应用连接指回老库这个过程可以做到秒级完成。第二层是切换完成且业务已经运行了短时间后的回退这时候就不能简单翻了要看有没有能力把新库产生的增量再反向同步回老库。如果一开始没建反向同步链路那就不存在这个回退选项。别把希望寄托在“手工补数据”上业务一旦跑起来手工补数据的量级是补不完的。另外一个常被忽略的点是回退后要不要保留新库。我建议无论切得多平滑都至少在切换后保留新库和同步进程运行一小段时间不要立刻停掉。因为有些业务问题不是切换当场爆发的可能是第二天跑批时才出现。真到了那时你留着一个已经跑了24小时的新库至少还能定位差异而不是两眼一抹黑。5. 常见问题与排查技巧实录最后这部分我把自己这些年处理过的典型坑整理成速查表遇到类似现场时可以对照着排查。这里面的每一条我都付出过加班的代价。5.1 丢数问题排查速查表现象最可能的原因排查方法全量后目标库行数就比源库少导出快照不一致或并发冲突重新做一致性快照导出检查工具的隔离级别设置增量同步没有报错但两边数据慢慢差开同步工具跳过了某类特定错误或目标库约束限制了写入查看同步日志中的warning对目标库约束逐项比对单表行数一致但业务对账对不上字段值被转换或截断常见于字符集、时区抽样对比原库和目标库的原始字段值重点看时间、金额、中文内容切换瞬间两边行数一致第二天发现少数据切换后仍有请求写入老库比如未变更的定时任务或缓存回写查应用日志中所有数据库连接串指向禁止任何残留连接目标库有重复键报错但同步进程继续跑同步工具默认跳过错误导致漏数据修改工具配置为错误暂停强制人工介入校验报告显示超大数据表差异但明细查不出来校验工具切分区间时遇到边界数据重叠或跨区间漏掉数据重新按主键区间分段叠加总行数和主键范围最大值最小值核对5.2 几个容易被忽视的“隐藏坑”第一个是源库的定时任务。很多系统晚上有跑批如果你恰好把增量追平和校验安排在跑批期间你就会看到两边数据忽上忽下一会儿一致一会儿不一致非常容易误判为同步链路有问题。我后来形成一个原则校验时间窗口永远避开源库定时任务高峰期除非你能把定时任务在演练时提前停掉并确认没有副作用。第二个是字符集和时区问题。国产数据库常常因为安装时选择的字符集和源库不一致导致varchar字段里的emoji、生僻字被替换成问号。更隐蔽的是日期时间字段源库是北京时间目标库如果session时区默认设成了UTC数据会整体差8小时。校验工具如果在代码里对时间字段做字符串比较反而可能因为格式化一致而掩盖掉底层时区错误。我教团队的土办法是迁移完随机抽几条记录让业务方用自己的查询界面看一眼原始值人的眼睛有时候比工具敏感。第三个是不建议切完就删源库。这个我说了很多遍但每年都有人踩。生产切换完成之后至少要保留源库只读状态一到两个完整账期具体时间看业务对账节奏。减持期间也不要动源库的任何存储过程、触发器、定时任务。有一个项目就是切完第三天源库的某个归档存储过程还在自动跑把一张没迁移完成的表数据清掉了等他们想起来还有问题要去源库找数据时已经来不及了。按照我自己的习惯切换后的第一个业务高峰期我会盯住三个指标不放目标库的慢查询数量、保留的增量同步延迟如果还在跑、应用侧的锁等待数。任何一项出现异常先看监控和日志再决定要不要干预切忌不做定位就重启应用。数据库迁移这件事说难是难在细节说不难只要你把流程设计得足够笨每一步都验证到零故障切换是可以做到的。