sql查询报数据截断

select  user_id 
from douyin_video_base 
WHERE user_id in(select user_id from user_table)

报错信息
1105 - other error: default not found: key:7480000000000000D45F72800000001A43E080, maybe read truncated/dropped table data?, Time: 555.805000s

找到了报错的具体id值了
select * from douyin_video_base
WHERE user_id=104761982553
就是这个user_id报错,但是在工具里查没有问题。


这是什么问题

2021/05/31 15:18:28.395 +08:00] [ERROR] [mod.rs:307] ["default value not found"] [hint=near_reverse_load_data_by_write] [key=7480000000000000D45F72800000001A43E080]
[2021/05/31 15:18:28.395 +08:00] [WARN] [endpoint.rs:537] [error-response] [err="default not found: key:7480000000000000D45F72800000001A43E080, maybe read truncated/dropped table data?"]
  1. 请问具体版本是什么?
  2. 能否反馈下表结构
  3. select _tidb_rowid,id,user_id from xxx where xxx; 查下 _tidb_rowid 是否有值,如果没有,应该是有哪一列可以作为唯一值
  4. curl http://{TiDBIP}:10080/mvcc/key/{db}/{table}/{handle} 从 3中查到的_tidb_rowid 查下mvcc信息,多谢。

版本是v4.0.11


{handle} 这个值是什么谢谢

有一个信息反馈给你。

报错:select aweme_id from douyin_video_base WHERE user_id=104761982553
报错:select * from douyin_video_base WHERE user_id=104761982553
不报错:select id from douyin_video_base WHERE user_id=104761982553
不报错:select user_id from douyin_video_base WHERE user_id=104761982553

看表结构 id 是主键,那么 id 就是 handle 值,可以反馈下信息,多谢。
curl http://{TiDBIP}:10080/mvcc/key/{db}/{table}/{handle}

@15810785091 麻烦帮忙反馈下信息吧,多谢

{
 "key": "7480000000000000D45F72800000001A43E080",
 "region_id": 7231696, "value": {  "info": {   "writes": [    {     "start_ts": 425208234893639852,     "commit_ts": 425208235548999721    }   ]  } }
}

这是报错id的详情,感觉和正常的缺少了value

多谢,在分析了,有进展会尽快同步

我们查找这个id时候报这个错误
select * from table where id='440656000'
1105 - tikv aborts txn: Txn(Mvcc(DefaultNotFound { key: [116, 128, 0, 0, 0, 0, 0, 0, 212, 95, 114, 128, 0, 0, 0, 26, 67, 224, 128] })), Time: 0.026000s

  1. 请问在出现问题前,集群遇到过什么问题吗? 比如断电什么的。
  2. 集群拓扑是什么? tiup cluster display 展现下当前状态?
  3. 麻烦在 tidb.log 和 tikv.log 搜索下对应的报错,上传下日志吧,多谢。

集群没遇到过啥问题好像


日志的话不知道啥时候出现的问题,日志也很大,等我搞出来再上传吧

@15810785091

  1. 请问这个集群有升级过吗?
  2. 这些信息是业务写入的,还是有使用过 lightning 或者 BR 导入或者恢复过?

看起来这个 key 是 8 天前写入的,查询的时候用时 555s,不到 10 分钟。帮忙确认下升级时间是什么时候,是否只有这个 key 有问题,可否提供 8 天前(5 月 26 日 22 时)至 3 天前(5 月 31 日 15 时)的日志

同一个集群,两个帖子重复