分布式微服务改造,到底怎么做数据迁移?

设计新系统容易，但是我们处理的都是老系统和历史诗句。怎么能更平滑的迁移旧数据到新的数据库和系统，特别是在异构的数据库结构情况下，达到数据准确，迁移速度快，减少停机，对业务影响小

迁移是最容易出故障的一个点。 那么如何做数据迁移呢？

1 解决方案

1.1 全量

最直观的一把梭方案，即全量数据的导入/出：

• 业务系统需要停机
• DB 迁移，校验一致性（数据、关系、约束等）
• 升级业务系统，接入新 DB

如果直接复制，可以 dump 后全量导入，如果是异构数据，需要用程序处理。 优点：简单 缺点：停机时间过长，数据量不太大时适合这种方案

1.2 全量+增量

大部分开发采用的方案，依赖数据本身的时间戳，即版本号：

• 先同步数据到最近的某时间戳
• 然后在发布升级时停机维护
• 再同步最后一段事件（通常是一天）的变化数据
• 最后升级业务系统，接入新数据库

优点：极大缩短停机时间

看来已经满足绝大部分需求了，还有更流弊的方案吗？

1.3 binlog+全量+增量（推荐）

当你的公司数据库和中间件比较完善时，推荐使用。

通过主库或从库的binlog解析和重新构造数据，利用主从复制实现扩展迁移，这需要中间件的支持。可实现多线程，断点续传，全量历史和增量数据同步。

可以达到：

• 实现自定义复杂异构数据结构
• 实现自动扩容和缩容，比如分库分表到单库单表，单库单表到分库分表，分4个库表到分64个库表

当然了，既然这种需求很常见，社区肯定也有支持的框架：

1.4 shardingSphere-scaling

• 支持数据全量和增量同步
• 支持断点续传和多线程数据同步
• 支持数据库异构复制和动态扩容
• UI界面，可视化配置