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是可以的,如下图

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

在文档中

那我要如何来调整数据类型的限制呢?把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中的测试

又踩坑了 :rofl:

这个参数你调整为多少了呢,截图看看?

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

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