为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
打开DM全量+增量同步数据到TiDB
线上读流量切换到TiDB，进行观察
没有问题后写流量切换到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存在差异，见下述文档：
https://pingcap.com/docs-cn/stable/reference/mysql-compatibility/#自增-id
有可能会出现主键冲突的报错，处理步骤需要通过修改位点或者删除下游已有数据的方式来跳过，可能存在数据不一致的风险。
TiDB是否可以设置自增的起始位置呢？这样可以为mysql写入提前预设好范围，防止主键的冲突
双写还有一个问题，在事务中。如果mysql或者tidb有任一方出问题。都会导致数据的回滚，感觉这个可能会较低我们服务的可用性。想问下在双向同步上有没有合适的方案推荐呢？因为我们切到TiDB后应该会有半年左右的时间继续向mysql同步数据，防止出现一些我们不好解决的情况，及时切回去。
谢谢，这个解决了我的主键冲突的问题
如果还有其他问题，请新开贴继续沟通，感谢配合～～～
好的，谢谢
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。