MySQL迁移方案的探索与落地

相关背景

1. 在Azure上的数据库是单个实例，未来可能会有部分库数据量激增，需要将其迁移到独立的实例中去，同时最小程度影响线上数据和服务运行。
2. 本次可以仅针对同区的数据库实例做迁移。

预期效果

1. 能够最小程度影响线上服务数据操作，将某个库从一个实例迁移到另一个实例中。
2. 最理想的情况是实现线上数据的平滑迁移，用户无感知、数据不丢失。

实现方案

DMS 存量增量迁移 + 直接切换

通过使用阿里云/Azure数据传输服务，将旧数据库实例存量和增量迁移到新的数据库实例，迁移完成切换服务连接到新的实例地址。

优点

1. 操作简单无需过多配置。
2. 业务代码无需改动。
3. 服务+数据库无需停机。

缺点

1. 对于数据写入频率高的库，因为数据同步可能存在延迟，切到新的库写入数据主键可能会和同步过来的数据主键重复，导致部分数据同步失败。

DTS 直接迁移 + 源端停写

基于 3.1 方案，在切换到新的DB链接前当DTS延迟为0时停止写入旧库（可以通过收回数据库写入和更新的权限实现），待切换到新库且DTS迁移完成再开启写入。

这里需要注意针对数据库账号变更权限对已经建立的连接是不生效的，需要重启连接池。

优点

1. 操作简单无需过多配置。
2. 服务+数据库无需停机。

缺点

1. 为了保证同步过来的数据主键和新写入的数据不重复，需要对源端做短暂的停写，对系统有一定的影响。
2. 需要改动业务代码，将其做短暂的停写处理。

DTS 存量迁移+增量旧新双写

存量数据通过DTS进行传递，当传递完成后通过开关将其停止同时将服务开启双写模式，同时以旧库主键为标准进行检查补偿，补偿检查的策略是如果存在冲突则使用旧库数据进行覆盖，运行一段时间后将流量切换到新库。

优点

1. 数据的完整度最高，不会出现数据同步失败导致部分数据丢失的情况。
2. 服务+数据库无需停机。

缺点

1. 成本比较高，需要更改程序支持双写（可以考虑在中间件级别来做或者主从复制）。
2. 需要编写数据补偿应用。

最终结论

1. 需要结合应用的数据库实际数据量、数据操作频率、数据重要性来选择对应的方案，不同的方案成本不一。

相关资料

1. 阿里云DTS：https://dtsnew.console.aliyun.com/migrate/task-config-next/base
2. Azure DMS 服务
   1. https://portal.azure.com/#browse/Microsoft.DataMigration%2Fservices
   2. https://www.youtube.com/watch?v=kzvLVZ_ChUE
3. 如何在不停机的情况下，安全地更换数据库： https://time.geekbang.org/column/article/221658
4. gh-ost：https://github.com/github/gh-ost
5. https://github.com/alibaba/yugong