Mysql向TiDB迁移的方案讨论

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】: v3.0.7, dm-v1.0.2
  • 【问题描述】: 我有一个这样的迁移规划,但最后一部分不知道是否可行,希望能给我一点建议和帮助。
  1. 打开DM全量+增量同步数据到TiDB

  2. 线上读流量切换到TiDB,进行观察

  3. 没有问题后写流量切换到TiDB,同时关闭DM。

第三步中可能部分服务在写Mysql通过DM写入到TiDB,部分服务直接写TiDB,表中主键使用的自增,这服务切换写地址的时候是不是会出现主键冲突的问题呢?会出现的话有没有什么好的解决办法吗?

在使用 DM 进行迁移时,以下是写流量的切换建议,请根据实际场景进行评估:

DM + 完全业务双写

该方案是在应用端实现双写,并且在指定时间窗口上线双写功能,运行稳定后,可评估写流量切换到 TiDB。

1)使用 DM 完成业务数据的全量和增量同步
2)寻找时间窗口将线上以及 DM 的流量同时切断,并确认数据是否完全同步
3)应用程序端上线双写功能
4)DM 不再作为增量同步的介质,评估后可计划下线
5)应用端正常写入数据到 MySQL 以及 TiDB
6)评估后,写流量切换至 TiDB

如果采用您之前提供的方案,业务 A 和业务 B 同时使用表 1 ,并且使用 DM 同步表 1 到 TiDB。DM 同步的粒度是 table,此时,切业务 A 到 TiDB,业务 B 会持续写入数据到 MySQL ,并同步到 TiDB。

MySQL 和 TiDB之间的自增 ID存在差异,见下述文档:

有可能会出现主键冲突的报错,处理步骤需要通过修改位点或者删除下游已有数据的方式来跳过,可能存在数据不一致的风险。

2赞

TiDB是否可以设置自增的起始位置呢?这样可以为mysql写入提前预设好范围,防止主键的冲突

双写还有一个问题,在事务中。如果mysql或者tidb有任一方出问题。都会导致数据的回滚,感觉这个可能会较低我们服务的可用性。想问下在双向同步上有没有合适的方案推荐呢?因为我们切到TiDB后应该会有半年左右的时间继续向mysql同步数据,防止出现一些我们不好解决的情况,及时切回去。

这里有类似的问题,可以参考下 修改自增主键的自增值

1赞

谢谢,这个解决了我的主键冲突的问题

如果还有其他问题,请新开贴继续沟通,感谢配合~~~

好的,谢谢

:handshake: