【TiDB 使用环境】生产
【TiDB 版本】8.5.1
我们有一个业务场景需要双向同步数据，具体如下：
PG/MYSQL -----> TiDB 用的是flnkcdc
TiDB -----> PG/MYSQL 用的是TiCDC+Kafka+flinckcdc再到目标端
两边都会写入数据，都需要同步到对方。TiCDC这边是否支持在抽取数据的时候额外加一个参数用来标识数据是同步过来的？用来判断 打破闭环
TiDB通过TiCDC的双向复制是怎么做到避免死循环的？AI回复：会加标识。不知道是否支持加自定义标识？
TiCDC 作为 TiDB 的变更数据捕获工具，在支持双向复制时确实提供了机制来避免这种死循环。
同步在mysql端上写入数据的时候，可以设置 SET SESSION sql_log_bin = 0，这样该操作就不会写入binlog，也就不会被CDC捕获了
TiCDC有这个能力，但是异构数据库双向同步的时候出现了这个问题
这样是解决了tidb向MySQL同步之后，防止再次同步回来的问题。MySQL同步到tidb的数据防止再次被ticdc捕获怎么操作？如果换成PG和tidb之间同步是否有同样的参数可控呢？
你光考虑循环的问题，不考虑事务冲突的问题吗？
两个数据库间又没有锁控制，冲突了怎么办呢？
如果一条数据被两个事务同时修改，以修改晚的为准。所以我的想法是在双向同步的中间引入一个中间服务，该服务负责消费源端的消息并记录相关 主键+修改字段名+字段值 的哈希值以及当前时间戳存到redis。同步的时候先根据当前修改记录做哈希比对，如果存在相同的哈希值就放弃同步，哈希不同以时间晚的为准。
这一条就要求2个系统之间需要一个统一的时间戳发放系统做中介。
也就是类似pd这样发放单调递增的tso。还要把tso记录在缓存里随时查询。
假设这两点你都能做到，还要面临同步性能的终极挑战。你用redis存可能好一点，但是时间戳肯定是要纳入比较的。不然怎么清楚那个记录是需要抛弃的。
是的，时间戳，也是比较的一部分
数据库层面没有想通怎么搞定这个异构数据库同步的死循环，如果分成几步，是否可行
真没见过这么玩的，高级 
这种情况我这边有计划推进过，多中心的不同业务的数据需要实时合并
单中心能支撑全球的数据副本的可用性…
AI 告诉你的答案没错的，但是需要在数据库的每个需要同步的表上给设定好标识
因为不同的库，对应的环境和地理位置只有部署的时候才知晓，
对于数据同步来说，只能依靠数据本身的标记，才能识别数据是从哪儿来的，需要分发到哪儿…
这个复杂度十分高，加油～
如果允许改表结构，则加两个字段：mysql_upd, tidb_upd，默认值为0，cdc端从mysql捕获写tidb的时候，设置mysql_upd=1，从 tidb->mysql 的时候，tidb_upd=1，这样任意两种数据库之间同步，你都能识别是业务还是cdc
有点高级，不敢这么玩