备案站点的跨库迁移与割接实践

割接的风险不在「切」，在「切之前没验够」

换云厂商、换数据库版本、单库拆分片、机房搬迁——这类项目的失败现场高度一致：方案评审时讨论的都是怎么切，真正出事的却是切之前数据就已经不一致了，只是没人发现。等到割接当天流量打过来，订单号重复、余额对不上、部分记录凭空消失，而这时候回滚窗口往往已经关上了。

关键要点

• 迁移分两段：存量搬运和增量追平，两段的衔接点（起始位点）是最容易出错的地方。
• 双写不等于一致：写入顺序、部分失败、并发覆盖都会制造差异，所以双写必须配校验。
• 切读和切写要分开做、分批放量，中间留出足够长的观察期。
• 回滚窗口必须显式保留：旧库要继续接收增量，直到新库被验证足够久。

整体节奏：六个阶段

阶段	做什么	完成标志
准备	新库建表建索引、参数对齐	结构与索引与旧库一致
存量迁移	全量搬运历史数据	记录数与抽样内容一致
增量追平	从存量起始位点持续同步	延迟稳定在秒级
双写	应用同时写新旧两侧	差异率持续为零
切读	读流量逐步切到新库	错误率与延迟无劣化
切写与收敛	写切到新库，旧库转为只读备份	观察期结束后下线旧库

最容易被压缩的是「双写 + 校验」这一段——它不产生可见进度，却是唯一能在割接前发现问题的环节。

存量与增量的衔接点

存量导出必须记录一个明确的起始位点（数据库的变更日志位置或一致性快照点），增量同步严格从这个点开始。两类典型错误：

• 位点取晚了：存量导出期间发生的变更被跳过，表现为少量记录莫名丢失，而且分布随机、极难复现。
• 位点取早了：部分变更被重复应用。只要同步逻辑是幂等的（按主键覆盖写入），重复是安全的——所以宁可取早，不可取晚。

存量搬运本身要分批限速，避免把旧库的 IO 打满影响线上，限速要点见 磁盘 IO 与文件系统运维，大表操作的注意事项见 数据库变更与在线 DDL 实践。

双写：比想象中更容易出错

双写的本意是让两侧都保持最新，但它引入了新的不一致来源：

来源	表现	处理
写新库失败但写旧库成功	新库缺数据	以旧库为准，记录差异待补
两次写入顺序相反	并发更新时新库留下旧值	按版本号或更新时间做条件写
事务边界不一致	旧库回滚了、新库却写进去了	新库写入放在事务提交后，失败只告警不阻断
只双写主表漏了关联表	关联数据不全	按表清单逐项核对

一条重要纪律：双写阶段以旧库为权威。新库写失败不能让业务失败，只记录差异并由补偿任务修复，否则迁移改造本身就成了新的故障源。补偿任务的幂等写法见 定时任务运维：幂等、防重与补偿。

校验：全量对总量，抽样对内容

只比对记录总数是不够的——总数相同、内容不同的情况非常常见。实用的三层校验：

1. 总量校验：按时间分片统计两侧记录数，定位差异集中在哪个区间。
2. 摘要校验：对分片内的关键字段计算摘要值再比对，能在不拉取全量数据的前提下发现内容差异。
3. 抽样明细校验：对差异分片拉取明细逐字段比对，输出可读的差异清单。

校验要持续跑而不是跑一次，并把「差异条数」做成指标曲线：差异数长期为零才说明双写稳定，见 可观测性建设。还要特别注意两侧的类型与精度差异（时间精度、小数位数、字符集与排序规则），这类差异在校验时表现为大面积不一致，实际是转换规则没对齐，时间字段相关的坑见 时钟同步与时区治理。

切读与切写：分开、分批、可回退

• 先切读：按比例逐步放量（1%、10%、50%，最后全量），每档观察错误率、延迟与业务指标。读切错了影响小且可秒级回退，是验证新库的最佳手段。
• 再切写：写切换是不可逆程度最高的一步。切换瞬间要短暂禁写（秒级），确保增量追平到位后再开放，避免出现双主写入。
• 保持反向同步：切写后把新库的变更同步回旧库一段时间，这是回滚能力的来源——没有反向同步，回滚就意味着丢数据。
• 流量切换的通用做法见 灰度发布与蓝绿部署，多实例并发下的互斥与选主见 分布式锁与选主实践。

割接当天的准备

• 明确回滚判据：写清「什么指标超过什么值就回滚」，而不是当场讨论。
• 禁写窗口预演：提前演练一次完整流程并计时，见 故障演练与预案验证。
• 两侧都做备份：切换前对旧库做一次完整备份并验证可恢复，见 数据备份与容灾。
• 连接与容量准备：新库的连接数上限、连接池配置要提前压过，见 数据库连接池与连接数治理；整体容量验证见 全链路压测与影子环境。
• 备案接入侧的确认：如果迁移同时更换了服务器、公网 IP 或接入服务商，属于备案接入变更，办理流程见 备案接入商变更流程。

常见坑

• 跳过双写直接停机割接：停机时间不可控，出问题只能硬扛。
• 只比总数不比内容：割接后才发现字段值早就不一致。
• 切写后立刻停掉旧库同步：回滚窗口直接消失。
• 双写失败阻断主流程：迁移改造本身成了故障源。
• 忘了关联表和历史归档数据：主表切干净了，关联查询开始报错。

常见问题

必须双写吗？停机迁移不行吗？

数据量小、可接受停机的站点，停机迁移更简单可靠。但停机窗口会随数据量增长而变长且难以预估，一旦超时就骑虎难下。双写方案的价值在于把风险拆成可回退的小步。

双写阶段要跑多久？

至少覆盖一个完整业务周期（含月末结算、对账等低频路径），并且差异条数持续为零。时间不是关键，「所有业务路径都被真实流量走过一遍」才是。

校验发现少量差异，可以直接补数据上线吗？

不建议。先定位差异的产生原因——是写入顺序、类型转换，还是漏了某条写路径。只补数据不修根因，割接后差异会继续产生。

旧库什么时候可以下线？

新库稳定运行、反向同步保持一段时间（通常数周）、且期间做过一次从新库的恢复演练之后。下线前做最后一次完整备份并按保留策略归档，见 数据生命周期与归档清理。

资料来源

主流数据库关于变更日志位点、一致性快照与逻辑复制的官方文档，以及公开的数据迁移与双写校验实践资料。本文为通用运维说明，仅供参考，具体方案请结合数据量、一致性要求与停机容忍度设计。