如标题，线上业务集群负载有 10000+ 的写（insert+delete+update+replace）QPS，使用TiCDC同步到 S3 或者同步到下游TiDB集群，有什么坑点需要提前注意？
1 个赞
如果同步到下游tidb集群（下游tidb集群当作异地高可用），从数据同步数据安全方面（非同步效率）我感觉有几个点需要注意：
1、关于数据定期比对，建议所有表必须为聚簇索引表，避免sync_diff工具做数据比对时候导致集群抖动，参考：sync_diff_inspector做上下游数据对比时可能会导致集群性能抖动
2、不使用lighning local模式导入数据避免数据不同步（对于特殊批次表，可以不设置同步，两侧集群分别local模式导数，减少ticdc带宽）
3、ticdc不会做用户、用户权限、密码的同步，需要自己维护。
4、ticdc不会同步sequence对象、视图，需要定期做检查，对于sequence的值也不会同步，需要像个办法定期同步并预测sequence的当前最大值，避免切换过去后sequence值比表中值还小导致业务失败。
5、如果主库做了SQL语句的binding，那么也不会同步到备集群中，需要定期同步binding情况。
上述3、4、5在做定期检查时候可以用https://gitee.com/wencycool/something_for_tidb/tree/main/tidb_object_diff来简单对比下。
我生产遇到过一次问题，有个集群cdc大概3000+的tps（主要是插入），同步到下游kafka。
下游的kafka磁盘io满了，cdc进程就卡住了，不同步也不报错，还好我写了个监控脚本，定时监控同步时间误差，修复好下游kafka后cdc任务还是处于卡住状态。重启了cdc服务后恢复正常。
2 个赞
之前通过ticdc 同步数据到mysql 出现问题较多，没敢在生产上面使用。后面通过ticdc 同步数据到tidb出现过，因为源端新建表没有设置主键造成ticdc同步失败的情况，后面通过上了审计工具限制一些不合理操作后解决。运行了半年了没有在出现过任何故障，很稳定
1 个赞
跟我思路相似。
问题：
1、同步卡住以后不报错，状态保持Normal，checkpoint时间静止
解决：
1、监控，获取checkpoint时间与当前时间对比
2、restart -R cdc
- cdc 默认单表只能在一个节点上，这么大量 1 个节点可能受不了，可以开启这个参数 enable-table-across-nodes 让单表按 Region 切分；
- 注意热点问题，上下游都要注意；
- cdc 要用高版本的，越高越好用
届时我们会邀请 TiCDC 的研发负责人来一一回应大家的需求和问题~
目前还没用上。dm用起来还挺顺手的。
有一次TIDB某个大表修改了字段类型，导致整个表的数据都重刷了一遍，下游kafka直接满了 
这个确实是有点猝不及防，TiCDC的同步原理是获取tikv的行变更来进行同步，上游修改表字段类型的时候会触发数据重新调整，应该是这个过程导致了整个表的KV数据都有变更，所以重新同步了一遍。这个在新版本应该是修复了 。
ticdc 在某些场景下会初现ddl 乱序，导致报错 6.5版本
1.如果暂停时间长一点而更新的数据量比较大， cdc拉取数据会大量占用内存， 而且迟迟无法同步数据， 这点我觉得没有pump/drainer靠谱。
- cdc的safe-mode机制也没有pump/drainer合理，
DM 跟cdc就不是一回事
在实践使用中我们也发现了这个问题，如果 TiCDC 同步流有延迟，出现重启（手动调参重启或任务自动重启）时，会有很高的瞬时 CPU 冲击，如之前遇到的一个案例在同步任务的延迟超过 20 小时后，手动重启同步流，瞬时消耗 CPU达到了 6000%（共8000%）。此时可能会带来一些额外问题，如果是和其他节点混部，可能会对集群产生冲击。
这也说明在极端场景，尤其是延迟接近 24h （GC safe point TTL）时，重启同步流会有很夸张的 CPU 瞬时冲击。这是因为 TiCDC 重启后需要重新全部获取落后的数据，重新进行落后这段时间内的变更数据拉取、排序和同步。
延迟越高，同步流重启时对节点资源消耗越多。所以，目前在官方未彻底解决这个问题之前，对于 TiCDC 同步流的延迟处理，要尽快处理。
1 个赞
龙虾大佬请教下，集群是v5.4.0的，能否使用高版本的ticdc组件，比如通过patch方式替换使用v7.5.x 的cdc。
大版本不建议跨，小版本可以，TiDB v5.4.x 的集群，可以单独把 cdc patch 到 v5.4.x 的最新版本
DM 踩得特别多，反倒是 CDC 没有踩过什么深大坑，反倒是有个比较渴望的需求趁机提一下 
考虑一下原生支持流量压缩，因为我们的场景是主要把 TiCDC 用在了异地灾备同步，流量费贵呀，现在是再前面顶了个 proxySQL 来做转发实现流量压缩~
1 个赞
近期项目上会把ticdc利用起来，哔哩哔哩上，看看ticdc源码解析。