1 背景

日常我们开发工作中，随着业务需求的变更，重构系统是很常见的事情。重构系统常见的一个场景是变更底层数据模型与存储结构。这种情况下就要对数据进行迁移，从而使业务能正常运行。

常见的表变化有如下3种：

1. 增加、删除、修改字段，对单表结构修改
2. 进行分库分表
3. 变更底层存储系统。例如数据库选型变更

当发生变更都要进行迁移。下面介绍3种常见的迁移思路。

2 停服迁移法

业务自身特点是非24小时提供服务，有暂停维护时间。这时可以在服务停止运行期间进行迁移。

操作方式如下：

• 数据迁移
  • 数据导出
  • 分库分表工具，分库分表场景下选择正确路由方式
  • 数据导入
• 数据对比
  • 数据量对比
  • 正确性对比
  • 路由策略验证（分库分表场景下）
• 切换数据源
• 恢复服务

方法分析：

• 一次性迁移，简单好处理
• 不存在一致性问题处理
• 业务需要停服
• 需要在指定时间内完成迁移

3 日志法迁移

mysql通过binLog完成主从同步，借助该思想完成迁移。 除了变更记录，还需要在分库分表场景下关注分表键或分库键，以及数据的时间戳。

操作方式：

• 发生数据变更操作时，记录变更日志，逐渐，路由信息
• 重放变更记录，完成新库写入
• 写入后进行数据对比校验
• 切换流量

方法分析：

• 这种方式对业务侵入性低。但是，当发生变更操作时就会产生新的日志记录。如果变更频率很高，会出现一致更新新系统。一段时间内数据无法一致，没法完成切换的情况发生。为了保证能够切换，变更业务在特殊场景下需要短暂停止。

4 双写法迁移

• 对原库上的数据修改增加双写，即写原库时，增加写新库的操作。原库写入成功算成功，新库写入失败需要记录日志。
• 通过对比工具，保证两库的数据一致
• 写失败记录进行重放，此时保证时序性，避免旧的更新将新的更新数据覆盖掉
• 读取数据切换到新库上
• 停写旧库，下线旧库双写代码

方法分析：

• 增加了业务代码的复杂度，及迁移流程增长。但避免了在写入量较大的场景下，新库更新追不上老库的情况。

5 总结

前文介绍了3种常见数据迁移思路。实际应用过程中可根据业务自身特点选择方案。此外根据数据库选型不同也有成熟的迁移工具可使用。避免重复的开发。