各位大佬，想问一个问题，我们现在是mysql5.7同步至tidb,打算使用dm进行同步，因为数据量就几十GB，所以用DM感觉稳妥，但是领导考虑到切换至tidb以后后续业务有问题，所以想着用CDC进行反向同步mysql，但是我们有个表是用了自增的，没有用tidb的auto_random，这种情况怎么用cdc反向同步mysql，如果把自增切换到auto_random，又怎么同步到mysql?
何不找个测试环境直接迁移测试试试看呢。
1 个赞
不使用auto_random，用非聚簇索引表+SHARD_ROW_ID_BITS+PRE_SPLIT_REGIONS,消除写入热点。
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#使用-shard_row_id_bits-处理热点表
这样是会损失一些性能，但是你要保险的情况下，性能考虑可以先放一放。
2 个赞
把mysql直接换成tidb不行么？不会也是有存储过程吧。
测试环境下有些数据不太一致，导致一些功能没办法测试到
没有，确实打算换，但是为了保险，所以还需要反向同步到mysql中
放心大胆的切 我们就是Mysql5.7直接切换tidb6.5 目有问题的
测试是保障，技术分析哪有测试来的准
你领导没信心啊，整个测试环境， 充分测试下就有底了
你的需求就是 mysql → tidb → mysql ?
何不考虑用 ticdc
我的理解是要双向
主要领导想同步以后，让tidb再反向同步mysql，但是我们测试环境就一台机子，所以自增永远是1，但是生产是集群，测试也不能测试
等应用停机后，停止DM，再启动ticdc同步到mysql，万一有问题可以回滚到mysql。auto_random也不是必选项，有自增列不影响同步。
可以，用 ticdc
用了自增不是auto_random也不影响通过cdc同步啊，切换成auto_random也不影响同步。。。
tidb的auto_random 也不影响cdc同步，同步只要求有主键就行
至于auto_random 本身也不是必要的，tidb用自增也没啥问题，tidb版本6.5以上开AUTO_ID_CACHE 1自增性能也可以的
如果使用自增auto_increment后，tidb的自增没办法保证顺序，比如1，2，3，4，5，tidb有可能会成为，1，2，3，4，5，1001，1002，这种，再用cdc的话，那mysql那边是不是也就变成了，1，2，3，4，1001，1002了？
问题是我是用的dm进行同步的，这个表创建好以后，没有AUTO_ID_CACHE 1,也没有办法进行修改表啊
字增列需看看你DML语句是什么，你所谓的12345，1001，1002这些是否通过DML语句显示的修改（一般来说字增列都是自动填充的），自动填充两边则会存在自增列不一致的状态。更建议TIDB这边开始就使用AUTO_ID_CACHE 1。DM同步表结构后是可以手动修改的