TiDB 日志报字段长度不够错误

blaine · 2021 年2 月 6 日 08:23

【TiDB 版本】v4.0.9

【问题描述】
tidb的日志里面出现很多字段长度不够的错误。

出现这些错误上下文并没有执行的sql。很奇怪。

Lucien · 2021 年2 月 6 日 11:44

应该是业务写入超过字段预设的大小的报错，可以从业务log 或者业务同学确认一下。看看需不需要做一下 DDL变更。

blaine · 2021 年2 月 6 日 13:02

这个错报的，不知道哪个库，也不知道i哪个字段，也不知道啥sql。就一个表。我们库都有这个表，要改，还要每个库都要改。业务测没有，如果有这样的，也就会插入数据报错了。而且这个错误会一直在刷

zhenjiaogao · 2021 年2 月 8 日 01:14

1、这个报错信息确实不友好，如果可以显示报错的 table name 和 column name 会更有利于定位问题～～

2、针对这个报错，可以尝试将 general log 打开，看能否打印出相关的 sql，general log 开启方式参考：

https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_general_log

blaine · 2021 年2 月 9 日 03:54

好的，感谢

懂的都懂 · 2021 年2 月 9 日 15:31

blaine · 2021 年2 月 17 日 03:54

这个字段长度报错又来了。现在开启了general log，但是也没有相关的sql。

，可以看出再这个报错的时候，io明显高了。，看到报错日志的上下有在analyze table ims_a08_51.`ims_task_user。我找到对应的库当中，查看，将字段15的长度改长了。就不报错了。可以看到io瞬间降下来了。日志也不报错了。但是问了业务那边，没有改动任务东西。但是这个错误真的很疑惑？io高的原因是，一直在analyze这张表。

QBin · 2021 年2 月 17 日 05:33

辛苦手动 analyze table 这个表看看能否重现这个问题。

blaine · 2021 年2 月 17 日 08:18

不会的。试过了

QBin · 2021 年2 月 17 日 13:25

麻烦提供一下以下信息：

curl http://{tidb_ip}:{tidb_status_port}/stats/dump/{db}/{table}
select @@tidb_config

blaine · 2021 年2 月 19 日 02:49

21.sql (17.8 KB)

QBin · 2021 年2 月 19 日 08:04

curl http://{tidb_ip}:{tidb_status_port}/stats/dump/{db}/{table} 这个结果没有给到。看上传的文档应该是请求了 4000 的服务端口，需要是请求 status_port (默认 10080)

blaine · 2021 年2 月 20 日 02:30

[root@ims-tidb-monitor ~]# curl http://172.16.0.57:10080/stats/dump/ims_a08_51/ims_task_user
[types:1406]Data Too Long, field len 15, data len 18[root@ims-tidb-monitor ~]# 直接报长度不够

QBin · 2021 年2 月 20 日 10:00

请问是线上环境吗？可以先选择非业务高峰期，先删除了这个表的统计信息，再重新收集统计信息。
再尝试执行 curl http://{tidb_ip}:{tidb_status_port}/stats/dump/{db}/{table} 看看有没有报错。

blaine · 2021 年2 月 22 日 03:13

是线上环境。暂时不敢动。等后面再说吧

这道题我不会 · 2021 年2 月 23 日 05:51

好的，有新进展了可以再反馈下

blaine · 2021 年3 月 17 日 03:52

根据之前的沟通，tidb日志里面总是报长度错误，删除统计信息，再分析表，同样还是报错。一直未能解决。

。只有通过添加长度才能解决。但是有的字段很长了，不能一直添加下去。业务也没有报错现象。只有日志里面有报错，又没有明确指出是哪个库，哪个字段。也没有报出是哪个sql导致的，很难判断是哪里的问题。

yilong · 2021 年3 月 17 日 08:06

看上面的描述，是指统计信息有问题，但是实际上表的结构没有问题吗？
开启general log 确认一个表的字段信息，应该是有日志提示的，从conn=id 最开始连接上了开始查找
麻烦 show create table 结构展示下，再看下找到的日志信息。
只有添加长度才能解决是什么意思？是业务侧插入的长度超过了表的定义吗？

blaine · 2021 年3 月 17 日 09:00

这个是为开启general log ,tidb 日志

回答您的1：不是统计信息有问题，是tidb日志里面报字段长度错误。
2：开启了general log，但是也没有具体的sql，这是截出来的日志 test.log (1.4 MB)
3： CREATE TABLE ims_sys_oper_log (
oper_id int(11) NOT NULL AUTO_INCREMENT COMMENT ‘日志主键’,
title varchar(50) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘模块标题’,
business_type int(2) DEFAULT ‘0’ COMMENT ‘业务类型（0其它 1新增 2修改 3删除）’,
method varchar(100) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘方法名称’,
operator_type int(1) DEFAULT ‘0’ COMMENT ‘操作类别（0其它 1后台用户 2手机端用户）’,
oper_name varchar(50) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘操作人员’,
user_id varchar(1000) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘会员账号’,
oper_url varchar(2000) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘请求URL’,
oper_ip varchar(50) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘主机地址’,
oper_location varchar(255) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘操作地点’,
oper_param text COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ‘请求参数’,
status int(1) DEFAULT ‘0’ COMMENT ‘操作状态（0正常 1异常）’,
error_msg varchar(2000) COLLATE utf8mb4_general_ci DEFAULT ‘’ COMMENT ‘错误消息’,
oper_time datetime DEFAULT NULL COMMENT ‘操作时间’,
PRIMARY KEY (oper_id),
KEY optime_idx (oper_time),
KEY idx_oper_name (oper_name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci AUTO_INCREMENT=120001 COMMENT=‘操作日志记录’ ；
4:添加长度是，是之前有很类似的报错，我都是通过改变字段的长度来解决的。例如：原先长度是varchar(10) 然后报错说最大需要50，会通过更改长度varchar(100)来解决报错的。但是这个问题一直都存在，且无法判断是哪里的原因。业务也没有报错的现象，如果不更改长度的话，日志会一直报错。

yilong · 2021 年3 月 17 日 11:37

请问您这边有升级过吗？还是这个集群一开始就是 v4.0.9
请问是正式环境还是测试环境，具体是什么业务？