ticdc 在高流量写入的情况下延迟问题

TiDB 使用环境: v5.1.2
【概述】
使用TICDC 将tidb 的数据同步到下游的kafka 中
每天下午会有较大的写入量，大概每天写入1亿数据。

%E5%9B%BE%E7%89%87920×290 74.5 KB

【现象】
TICDC 延迟会持续增加，到第二天依然不能追平。如下图

%E5%9B%BE%E7%89%871840×561 111 KB

%E5%9B%BE%E7%89%871835×621 150 KB

【问题】
请问如何优化这种情况 ？

如下是创建的changefeed 的参数配置,是否有可调整的？

tiup cdc cli changefeed  create   --pd=http://xxxxx:2409  
--sink-uri="kafka://xxxx:9092/tidb_zb_apm?partition-num=3&max-message-bytes=10485760&replication-factor=1"  
--changefeed-id="cdc-zbapm-kafka" 
--config=/home/tidb/cdctoml/cdc-tidb-zb_apm/cdc_tidb-zb_apm-kafka.toml  --sort-engine="unified"

##toml 文件
case-sensitive = true
enable-old-value = true

[filter]
ignore-txn-start-ts = [1, 2]
rules = ['zb_apm.*']

[mounter]
worker-num = 6
[sink]
dispatchers = [
   {matcher = ['zb_apm.*'], dispatcher = "table"},
]
protocol = "canal-json"

==========>
目前问题已基本定位到了。
我们使用的下游kafka 是腾讯云的, 参数 message.max.bytes 最大是12M. 当前这个参数设置的额值较小。
我们创建的changefeed 的max-message-bytes=1048576 设置为10M,如果超过这个值就会报错message too large.

联系了kafka 的维护人员将腾讯云kafka 的message.max.bytes 设置为10M, ticdc 同步瞬间追平了。问题解决

%E5%9B%BE%E7%89%871839×538 96 KB

可以自己给自己设个解决方案～ 打个标，方便其他的小伙伴查找到

应该怎么标注，之前是可以设置为有用。我自己这个怎么弄？

我给你标注了～

kafka的message.max.bytes值从12MB改成10M ，改小了，确定是这样改的吗？

腾讯云最大的这个值是12M. 之前不知设置的多少，维护人员改成10M 后延迟下来了。但是今天又特么延迟了，还在排查

完蛋，又延迟了。还是麻烦给看看我上面的配置有没有优化的空间吧，感觉要救不活了

从上文中可以推出可能不是cdc的问题，broker.message.max.bytes从12MB–》10MB，需要重启broker，归根结底是重启broker后，消除了cdc延迟，这也暗示了 排查方向是kafka集群，看看kafka集群的负载情况。

延迟是 CDC 延迟推送了，还是 什么？
如果是延迟推送，需要检查几个点：

1. CDC 的状态
2. Kafka 消费状态

参数能调的就这么几个，你可以试试

image825×234 21 KB

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-ticdc#如何查看-ticdc-同步任务的状态
看看状态是否正常…

我上面的描述可能不太清楚哈。
第一次是将kafka 的那个参数 message.max.bytes 从一个较小的值调整到了10M(不是从12M 调整到了10M), 调整之前多大我不清楚
下图是维护人员调整完的截图

%E5%9B%BE%E7%89%871146×204 13.3 KB

当时cdc 的延迟在很短的时间内就消除了延迟，没想到晚上又开始延迟了

%E5%9B%BE%E7%89%871834×270 56.4 KB

我下周一再让他们调整下kafka 其他的几个参数

另外还有一个疑问，如果是kafka 消费慢，应该是只有checkpoint 有延迟，为啥上图中的Processor Resolved ts lag 也很大呢 ，我下面的理解是否正确 ？？

我理解这个指标是 cdc 解析tikv 日志的进度，如果下游消费来不及则就会生成磁盘临时文件。对于cdc 来说resolve 是没有延迟的，只是在等待下游消费。如下图是磁盘临时文件的监控:

%E5%9B%BE%E7%89%87908×284 25.6 KB

好的。我下周再让他们把其他的参数都调整一下。多谢

Processor Resolved ts lag 这个指标不是 cdc 解析 tikv 日志的进度，它和 Changefeed checkpoint lag 是正相关的。
如果下游卡住了，消息无法写下去，Changefeed checkpoint lag 不断增大，则 Processor Resolved ts lag 也会不断增大的。

checkpoint-ts 代表当前 processor 已经成功写入下游的事务的最大 TSO
resolved-ts 代表当前 processor 中已经排序数据的最大 TSO

Processor Resolved ts lag=time() - ticdc_processor_resolved_ts
Changefeed checkpoint lag=time() - ticdc_processor_checkpoint_ts

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。