如何实现mysql不停机不停业务迁移_双写方案与数据一致性校验

如何实现MySQL不停机迁移：双写方案与数据一致性校验

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

话说回来，数据库迁移这事儿，听着简单，做起来处处是坑。核心就一句话：双写必须在统一事务边界内执行，典型做法是先写主库再写备库并配补偿机制；一致性校验需分片比对哈希值，注意字段顺序与NULL处理；双写开关须运行时灰度控制并设TTL；切流前需验证反向同步能力。 下面咱们就拆开揉碎了，把这几个关键点聊透。

双写方案里，INSERT 和 UPDATE 必须走同一事务边界

首先得明确，双写可不是在应用层随手发两条SQL那么简单。最要命的是什么？是把新旧库的写操作，塞进同一个数据库事务（或者靠谱的分布式事务框架）里。否则，数据不一致就是板上钉钉的事。用MySQL自带的XA事务？成本高、兼容性也让人头疼，所以更常见的路子，是在应用层用本地事务，再配上补偿逻辑。

典型的操作流程是这样的：先写主库（也就是旧库），成功了，再接着写备库（新库）。如果第二步失败了，麻烦就来了——必须触发回滚，或者至少要有异步重试机制，同时把失败日志记下来，方便后续人工介入。千万别抱着“写完就算”的侥幸心理，网络抖动、连接超时、甚至主键冲突，都可能让第二条INSERT夭折，而第一条却已经提交了，这烂摊子可不好收拾。

• 统一收口是铁律：所有双写路径必须收敛到一个统一的服务方法里，严禁各个业务模块自己搞一套，否则后期维护和排查就是噩梦。
• 失败要有降级策略：写新库一旦失败，不能粗暴地直接抛异常把用户请求打断。正确的做法是降级为只写旧库，同时给数据打上类似need_sync的标记，留作后续对账补偿的线索。
• 远离存储过程和触发器：别想着在MySQL的存储过程或触发器里实现双写。触发器根本没法跨实例，而且一旦出错，上下文信息全被掩盖，排查起来欲哭无泪。

校验阶段用 CHECKSUM TABLE 只适用于小表，大表必须分块比对

说到数据一致性校验，很多人的第一反应是CHECKSUM TABLE。但实话实说，这命令在千万级别以上的大表面前，基本就是个“花瓶”——它会锁表、狂吃CPU，线上查询能被拖慢到怀疑人生。所以，生产环境里真正靠谱的校验，得按业务主键范围，把数据切成片，一段一段地比。

举个例子，按id分页：先查出表的id范围，然后用BETWEEN拆成每1万行一段，分别去旧库和新库计算MD5(CONCAT(...))或者CRC32值来比对。这里有个魔鬼细节：字段顺序、NULL值处理、甚至是时间字段的精度（比如DATETIME(3)和DATETIME(6)），都必须保证完全一致。否则，哈希值对不上，可能只是因为这些格式差异，数据本身反倒没问题。

• 跳过“噪音”字段：校验脚本必须主动跳过像UPDATE_TIME、CREATE_TIME这类自动生成的字段，它们在双写时天然就是不同的，比了也没意义。
• 效率优先：用SELECT ... INTO OUTFILE导出再比对的法子，效率低且给磁盘带来巨大压力。优先考虑通过JDBC或数据库连接器直连，进行流式比对。
• 保持表结构稳定：校验期间，严禁在旧库执行OPTIMIZE TABLE或ALTER TABLE这类操作，它们会改变ROW_FORMAT，导致CHECKSUM值失效，前功尽弃。

双写开关必须支持运行时灰度，不能靠改配置重启生效

准备上线双写？别急着全量铺开。得先放一小部分流量（比如按用户ID取模）去走新库，把读写链路彻底验证通了再说。这就要求你的双写开关逻辑，必须嵌入在DAO层，能够动态生效，而不是依赖修改application.yml配置文件再重启服务这种“石器时代”的做法。

一个被广泛验证过的方案是借助Redis存储开关状态：SET write_new_db:order 1 EX 3600。在代码里，通过redisTemplate.opsForValue().get(“write_new_db:” + bizType)来判断。这么做的好处显而易见：你可以随时关闭某个业务线的双写，而不至于牵连整个系统。

• 开关要足够精细：开关的key一定要带上业务维度（比如user、order），避免一刀切，导致不必要的全局降级。
• 给开关加上“保质期”：必须设置TTL（生存时间）。这是为了防止运维同学忘了关闭开关，导致系统长期处于双写状态，白白放大延迟和消耗资源。
• 变更留痕：任何对开关的操作，都必须记录详细的审计日志，包括操作人、时间、影响范围，方便事后追溯和定责。

最终切流前，必须跑通「反向同步」兜底能力

切流，可不是把旧库一关就万事大吉了。最怕的是什么？是新库突然出问题，比如慢查询堆积、连接池被打满。这时候，你得有能力在5分钟内快速切回旧库。这就要求，反向同步通道必须始终在线——也就是说，新库的变更也得实时写回旧库（哪怕只同步关键字段）。

技术选型上，可以用Canal或Debezium这类工具捕获新库的binlog，过滤出双写涉及的表，再通过一个轻量级的消费者写回旧库。这里有个关键点：反向写入时，一定要跳过那些双写标记字段（比如sync_flag），否则就会陷入循环同步的死循环。

• 监控同步延迟：反向同步的消费延迟必须纳入监控，一旦超过10秒就要触发告警。因为这个延迟，直接代表了故障回切后可能丢失的数据量。
• 慎用逻辑备份做兜底：不要指望用mysqldump --single-transaction来做关键时刻的兜底备份，它无法保证与双写时间点的严格一致性。
• 旧库别急着下线：切流完成后，旧库至少要保持72小时的只读状态。等到所有双写任务确认完成、反向同步通道也运行稳定之后，再考虑下线事宜。

其实，整个迁移过程中，最难的部分往往不是写代码，而是判断哪些表能安全地双写，哪些表必须停下来做迁移。比如那些包含外键级联删除、全文索引、或者GIS空间字段的表，双写时极易因为存储引擎差异（InnoDB vs MyRocks）、函数兼容性问题（不同版本JSON_EXTRACT的行为可能不一致）而出错。这些风险，绝不能靠文档拍脑袋决定，必须提前在预发环境，用真实的流量进行充分压测和验证。