我们也遇过，我们是造成了内存高
这个是哪个版本？
服务器内存别太小气
相关卡住状态，不告警，数据不更新，这种状态比较费劲些
1 个赞
感谢上面各位大佬的回答，这里总结下使用ticdc可能遇到的问题以及避免采坑的建议：
大家遇到过的问题：
- 使用TiCDC同步，定期用sync_diff工具做数据比对时候导致集群抖动，影响线上业务。
- 使用lighning local模式导入数据，ticdc无法捕获变更数据，导致数据不同步。
- 下游的kafka磁盘io满了cdc进程卡住，不同步也不报错，修复好下游kafka后cdc任务还是处于卡住状态，需要人工介入重启了cdc服务后恢复正常。
- 源端新建表没有设置主键造成ticdc同步失败。
- 某个大表修改了字段类型，导致整个表的数据都重刷了一遍，下游kafka直接满了 。
- 如果 TiCDC 同步流有延迟，出现重启（手动调参重启或任务自动重启）时，会有很高的瞬时 CPU 冲击。
- TiCDC出现卡住状态，也不告警不失败，同步到下游的数据也不更新，比较难排查问题。
- 使用ticdc 过滤DDL后，相同表的DML也会被过滤。这是低版本的bug，在新版本已经修复。
使用ticdc避坑建议：
- 在新版本集群建议使用sync_point功能，定期校验数据一致性情况。用sync_diff工具时，也建议在业务低谷期进行。
- 不使用lighning local模式导入数据避免数据不同步（对于特殊批次表，可以不设置同步，两侧集群分别local模式导数，减少ticdc带宽）
- ticdc不会做用户、用户权限、密码的同步，需要自己维护。
- ticdc不会同步sequence对象、视图，需要定期做检查，对于sequence的值也不会同步，需要像个办法定期同步并预测sequence的当前最大值，避免切换过去后sequence值比表中值还小导致业务失败。
- 如果主库做了SQL语句的binding，那么也不会同步到备集群中，需要定期同步binding情况。
- 源端的表必须要有唯一键，包含主键。
- cdc 默认单表只能在一个节点上，这么大量 1 个节点可能受不了，可以开启这个参数 enable-table-across-nodes 让单表按 Region 切分。
- cdc 要用高版本的，越高越好用。
- 如果 TiCDC 同步流有延迟，延迟越高，同步流重启时对节点资源消耗越多，所以对于 TiCDC 同步流的延迟处理，要尽快处理。
- TiCDC大版本不建议跨，小版本可以，TiDB v5.4.x 的集群，可以单独把 cdc patch 到 v5.4.x 的最新版本。
TICDC支持对临时表的同步吗？视图不能同步的话是只能手动在sink建立？
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。