技术方案之数据迁移方案
一、序言
随着业务的发展，单个 MySQL 实例往往难以满足性能、存储和高可用的需求。此时，团队需要将旧库的数据迁移到新的 MySQL 实例（如云数据库、分库分表架构）。迁移过程必须兼顾 存量数据的完整搬迁 和 增量数据的持续同步，以确保数据一致性和业务连续性。
二、停机方案
停机迁移是最简单的方式：
停止应用对数据库的写入；
使用
mysqldump、mydumper或物理备份工具（如xtrabackup）导出全量数据；将数据导入新库，校验一致性；
切换应用到新库再启动业务。
优点是实现成本低，数据一致性高；缺点是停机时间不可避免，适合业务体量较小或能容忍短时间停机的场景。
三、不停机优雅迁移方案
在大多数生产环境，停机迁移不可接受，因此需采用“全量 + 增量”结合的方案：
全量迁移：使用
mydumper、xtrabackup等工具将旧库全量数据迁移到新库；增量同步：基于 binlog 或 CDC（Change Data Capture）机制捕获旧库写入操作，并实时回放到新库（常用工具：Canal、Debezium、DTS）；
双写验证：在迁移期间，应用可选择性双写新旧库，对比校验数据一致性；
平滑切换：待增量数据追平、校验通过后，将应用流量逐步切换到新库，实现无感知迁移。
这种方式虽然实现复杂，但能做到业务不停机，适合高并发、核心系统场景。
完整流程：
存量迁移 → 开启增量同步 → 增量追平 → 校验 & 双写 & 检验 → 读灰度切流 → 读全量切换 → 关闭双写&关闭CDC → 旧库下线。
关键技术：
在打开双写的时候，CDC还要继续同步，这是为了防止打开双写的瞬间丢数据，那么这里就需要做好幂等方案，比如主键，比如业务做幂等，再比如upsert等，防止CDC和双写重复写的问题。
四、总结
MySQL 数据迁移的核心是 存量数据一次性搬迁 与 增量数据实时同步 的平衡。停机迁移简单但有业务中断风险，不停机迁移复杂但能确保连续性。实际落地时，团队需要结合业务重要性、数据量规模和可接受的风险选择合适方案。最终目标是：既保证数据的一致性，又不影响业务连续运行。
欢迎关注，一起交流，一起进步！