Bug 反馈
清晰准确地描述您发现的问题，提供任何可能复现问题的步骤有助于研发同学及时处理问题
【 TiDB 版本】V7.1.3
【 Bug 的影响】
出错的changefeed监控了两表有大字段的表，由v7.1.1 升级至 v7.1.3之后出现如下图的错误，之前v7.1.1的时候没有出现过类似的问题，看出错也不像是消息过大（kafka消息大小限制远超过报错的值）
【可能的问题复现步骤】
由v7.1.1 升级至 v7.1.3, 表有longtext，可能消息比较大
【其他背景信息或者截图
日志也没有更多的信息：
调大 kafka message size 试试呢？
kafka message size 的大小超过报错大小的两倍还不止，感觉不是这个参数的问题
Kafka日志有东西吗
+1，很多时候TiCDC的告警详情都在日志里，上下文比较丰富
这上面看不出来，看一下CDC具体的日志
能否提供一下 CDC 和 kafka 日志？
cdc的日志已补充，kafka没动过，应该不是kafka的问题
已截图上传
升级期间kafka配置未做过任何调整，应该不是kafka的问题
重启 changefeed 之后还会继续报这个错吗？
你的猜测是对的，应该是消息比较大导致的
未测试此情况， 现场已丢失
最终是如何解决的呢？
估计还没解决… 静观…
没动过kafka的配置的话，如果tidb升级前同步正常，升级后报错。建议检查 kafka是否正常。升级阶段有没有表结构变化，有没有新增表的同步。检查对应主题。
知道大字段容易出问题，特意把大字段的表单独建changefeed， 另外所有的表用一个changefeed，非大字段changefeed表非常多，运行正常，且kafka参数未做任何调整，所以应该不是kafka的问题。 应该还是升级之后消息大小哪里限制了
问题重现，重启无效
TiCDC上游、下游是相同的集群，唯一的差异就是同步任务不同。说明上游tidb集群和下游kafka应该是正常的。
把大字段的表单独建changefeed，这个任务有问题；非大字段changefeed表非常多，运行正常，这些任务没问题。这里的现象就说明老师大字段触发的问题，加上上面的日志报错显示： TiCDC 发送日志消息到下游kafka报错，原因是由于 invalid request size 而导致无法正常生产出消息发到下游。
所以，这里应该是有内部检查逻辑，控制了这个消息大小的判断阈值。可以看下源码具体是哪个参数控制的，再针对性调整。
