真正可行的无缝迁移路径只有双写过渡或基于binlog的CDC同步；mysqldump因导入锁表、无法捕获增量变更，必然导致数据不一致，不满足无缝要求。

mysqldump 不足以支撑“无缝”迁移，真正可行的路径只有两条：**双写过渡**或**基于 binlog 的 CDC 同步**。其他方案（如纯逻辑导入、物理拷贝）必然伴随停机或数据断层，不符合“无缝”定义。

为什么不能直接用 mysqldump + 停机切换？

因为“无缝”意味着业务无感知、写入不中断、查询不降级。而 mysqldump 导出期间虽可用 --single-transaction 保证一致性，但导入过程会锁表、阻塞写入，且无法捕获导入窗口内的新增变更——哪怕只差 1 秒，数据就已不一致。实际生产中，只要写入 QPS > 50，这个窗口就不可控。

canal + 全量+增量同步的实际配置要点

这是目前落地最稳、侵入最小的方案，但配置细节决定成败：

DrugBank 数据库

访问并分析来自 DrugBank 数据库的全面药物信息，包括药物属性、相互作用、靶点、通路、化学结构和药理学数据。用于药物数据、药物发现研究、药理学研究、药物-

下载

• 全量阶段必须在 canal 启动前完成，且导入时需禁用目标库的外键和唯一约束（否则分片后主键冲突或唯一索引报错）
• canal 的 destination 配置要与 MySQL 的 server_id 严格区分，避免与现有从库冲突
• binlog 格式必须为 ROW，且 binlog_row_image = FULL，否则 UPDATE/DELETE 事件丢失旧值，分片路由无法判断原记录归属
• 分片路由逻辑不能写死在 canal adapter 里，建议抽离为独立服务，便于灰度验证和热更新

双写方案里最容易被忽略的事务一致性陷阱

应用层双写看似简单，但以下三点常导致线上事故：

• 旧库写成功、新库写失败时，若仅靠重试而不记录失败日志，重试窗口内重复写入可能触发分片键冲突（例如同一 user_id 被哈希到不同分片）
• 未对 INSERT ... ON DUPLICATE KEY UPDATE 做兼容处理，MySQL 的 REPLACE INTO 在分库分表中语义完全不同，极易覆盖非预期数据
• 双写中间件（如 ShardingSphere-JDBC）若未开启 xa_transaction_manager，跨库事务回滚会丢失，只能靠事后补偿，而补偿逻辑本身又依赖新库可用——形成单点依赖闭环

切流前必须验证的三个数据状态

切换不是改个连接地址就完事。上线前至少要确认：

• 新库的 SELECT COUNT(*) 和旧库完全一致，且按分片键分组统计（例如 GROUP BY user_id % 4）各分片数量均衡
• 关键业务表的最新 100 条写入记录（按 create_time DESC）在新旧库中字段值逐行比对，尤其注意 TIMESTAMP、JSON 类型是否自动转换失真
• 旧库 binlog position 和 canal 消费位点严格对齐，且 canal client 端无堆积（msgId 差值

真正难的不是技术选型，而是把「分片键选择」和「路由逻辑收敛」提前嵌入到双写或 CDC 的数据流转链路里——一旦新库开始承接读流量，所有 SQL 就必须能被唯一映射到某个分片，没有模糊地带。这点在订单号含时间戳、用户 ID 经过脱敏处理等场景下，极容易被忽略。