drainer同步text字段时报error="Error 1406: Data too long for column '' at row 1"

【 TiDB 使用环境】生产环境

【 TiDB 版本】
上游为v5.4.1
下游为v6.5.0
通过drainer把v5.4.1的数据同步到v6.5.0

【复现路径】做过哪些操作出现的问题
今天把下游tidb升级到v6.5.0，下游在升级前也是v5.4.1

【遇到的问题：问题现象及影响】
升级后，drainer报错，
[error=“Error 1406: Data too long for column ‘xxxx’ at row 1”]
[2023/03/20 16:58:59.522 +08:00] [ERROR] [executor.go:135] [“Exec fail, will rollback”] [query="REPLACE INTO xxxx.xxx_xxxx_log(

表中有字段中有两个类型是text类型，我尝试把上游表mysqldump出来，然后导致到个人测试v6.5.1版本中是可以正常导入，
因此请帮忙是否是在v6.5.0版本有兼容问题？
此时我要如何跳过这条记录呢？（我可以手工跳过此表，但如果其他表也有类似情况，那就不可以通过跳表解决了）？
升级时，我们是需要先升级上游还是先升级下游呢？是否可以避免此类问题。

【资源配置】
【附件：截图/日志/监控】
生产环境，因此不可以在页面上提供表、列、ip、数据等信息。

统计信息收集报错 Data too long for column 'upper_bound' 看看这个是否对你有用？

统计信息相关在v5.3版本中做了修改。

我环境是v5.4.1与v6.5.0，我也查看了系统表表结构，三个列都已经是longblob类型了

在上游中查看，表中出现问题的id数据量时，发现为71797
select length(json_result) from xxxx.xxx_xxxx_log where oper_id=xxxx;
±--------------------+
| length(json_result) |
±--------------------+
| 71797 |
±--------------------+
1 row in set (0.01 sec)

mysqldump导出来后，手工导入个人测试环境v6.5.1中后查看，发现同样id大小为65535
select length(json_result) from xxxx.xxx_xxxx_log where oper_id=xxxx;
±--------------------+
| length(json_result) |
±--------------------+
| 65535 |
±--------------------+
1 row in set (0.00 sec)

因此是不是大v6.5.1版本中对text有某些限制呢？

drainer 的支持性对于5.X 就有不兼容的地方， 至于6.X 就差太多了… 就没办法支持了

建议你切换成 ticdc…

我把出问题的这条记录复制成insert语句，然后在两个环境中做了测试
在v5.4.1中，我手工插入sql是可以的，如下图

image977×246 35.2 KB

在v6.5.1版本中，手要插入时报错，如下图

image976×203 33 KB

在文档中

image697×685 25.1 KB

那我要如何来调整数据类型的限制呢？把text调至大于6M

在
https://docs.pingcap.com/zh/tidb/dev/tidb-configuration-file#txn-entry-size-limit-span-classversion-mark从-v50-版本开始引入span
有 txn-entry-size-limit，此参数在v6.5.1中调整后，再次insert上面sql还是报错。

在v5.4.1中可以插入超过65535的这行记录，这个严格来说是bug。

我在mysql5.7.39中做了insert测试，发现也是data too long，跟v6.5.1中行为是一样的

说明：
对于text类型可以超出65535，这属于bug，在v6.5.1中把这个bug修复了。

下图是在mysql中的测试

image929×222 35.9 KB

又踩坑了

这个参数你调整为多少了呢，截图看看？

跟这个参数关系不大，是text类型长度问题，v6.5.1版本跟mysql的行为一致了。而之前版本会把大于65535的成功插入。

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