上游的cdc版本是什么，低版本的cdc有bug，参考这个https://docs.pingcap.com/zh/tidb/v5.4/troubleshoot-ticdc#ticdc-占用多少-pd-的存储空间

这个是由于cdc 4.0.16和pd版本不兼容导致的，我也遇到了

遇到同样的问题

因为是在做4.0.2到5.4.0的数据迁移，迁移后使用sync_diff_inspector校验上下游的数据，由于sync_diff_inspector对float和double类型的数据使用round()函数保留6位和15位有效数字，导致上下游的数据校验失败，因为4.0.2使用round()函数会四舍五入 ，而5.4.0直接截断了

排查发现大内存的那个节点是stats owner节点，为了避免影响业务，我们将该节点重启后，新的stats owner又出现内存持续增长，感觉像是内存泄漏

慢日志有，各节点也都有，其他节点的慢sql不比这个节点少，可是就这个节点的内存一直居高不下

这个结果已经贴出来了 [image]

这个看了一下，这个节点和其他节点的请求都差不多

能从内存分布看出是慢查询导致的吗？

[image] goroutine count没有增长，而且各节点都差不多

ticdc在同步大事务的时候有什么办法优化一下吗，目前的同步进度一直卡住，ticdc的版本是5.3.0

数据的流向应该是puller->sorter->mounter->sink，不应该是在sorter就停止输出了啊

使用tiup部署实例支持ipv6吗？

我最想要获得PCTP考试资格

因为有一段时间有一张表删800万行数据，导致了有一个cdc节点负载过高，刷新到下游的速度跟不上，然后那个节点的checkpointTs一直没有变化，没有报错，有没有什么方法调优一下，另外上游到下游的网络带宽只有100M

昨天的query查看状态是normal，cdc.log一直在刷Unified Sorter: trying to create file backEnd，现在changefeed已经faild了，报这个 “message”: “[CDC:ErrGCTTLExceeded]the checkpoint-ts(436308863790350610) lag of the changefeed(simple-replication-task) has exceeded the GC TTL”

ss -ltn | grep 4000

检查一下tidb服务是否在监听4000端口，虽然systemd显示启动，但是可能它并没有在监听4000端口，tiup部署实例时是通过查看4000端口是否被监听来判断该组件是否被启动成功

cdc cli changefeed query --pd=http://xx.xx.xx.xx:2379 --changefeed-id=“zjp-task4” 看看同步状态，另外创建的命令里的uri应该是 --sink-uri="tidb://root:admin@yy.yy.yy.yy:4000/”