tikv 一直报no valid key found for split.\

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】 tidb 4.0
【概述】场景+问题概述
【背景】做过哪些操作
【现象】业务和数据库现象


【业务影响】
【TiDB 版本】tidb4.0
【附件】

  1. TiUP Cluster Display 信息

  2. TiUP Cluster Edit Config 信息

  3. TiDB- Overview 监控

  • 对应模块日志(包含问题前后1小时日志)

集群有3个Tikv,一个报

另两个报

麻烦提供一下文本 log,图片最近打不看,不清楚 :joy:

图片看不清楚,可以重新贴一下原图吗?

1.麻烦反馈下具体的 tidb 集群版本,以及在报错开始前是否对集群做过什么操作;
2.从日志中看报错提示的是固定的某几个 region ,可以先看下具体的 region 状态:
(1)查看下 region 状态是否正常:
tiup ctl:<cluster-version> pd -u <pd_ip:pd_port> region <region_id>
(2)如果 region leader 和副本状态均正常,可以看下 region 的mvcc.num_rows 是否很多:
tikv-ctl --host <tikvip>:<tikvport> size -r <region_id>
tikv-ctl --host <tikvip>:<tikvport> region-properties -r <region_id>
(3)若 num_rows 也很多,看下当前集群的 gc 配置是否很长:
select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like "tikv_gc%";
如果上面几条内容都满足的话,可能是一个已知的 bug ,可以降低 gc 时长看下效果
update mysql.tidb set VARIABLE\_VALUE="xxx" where VARIABLE\_NAME="tikv\_gc\_life\_time";

1 Like

https://asktug.com/uploads/default/original/4X/4/c/3/4c3e4cf87369ad56498a2d31749e0047968fde5d.png

图片点击得了了~

这是region不存在吧?

这里 tikv_gc_life_time 设置为 720h 确实有点太长了,不知你这边设置这么大的原因是什么,现在可以考虑逐步减少 tikv_gc_life_time 的值,将过旧的 region 版本数据清理掉,这个问题应该会有所缓解。

tikv_gc_life_time 这个参数修改小了会影响保留数据时长吗?

会影响的,不建议将该值设置的过大,保留了太多了旧版本数据会对集群的性能有明显的影响,具体 GC 机制可以参考下:https://docs.pingcap.com/zh/tidb/v4.0/garbage-collection-overview#整体流程

是不是热点问题造成的?现在有两张上亿的大表在批量写入。现在GC调整多久合适?

1.这个跟热点有一定关系,但主要还是 GC 时间设置的时间太长导致积累了大量旧版本的数据,放大了这个问题;
2.GC 调整为多久(即能查看多久前的旧版本数据)需要看你们业务以及运维的需求,但不建议一下子将时间调整的很小,防止因短期内删除大量旧版本数据引起集群性能的波动,可以适当进行下流控:
(1)gc 限流
tikv-ctl --host=ip:port modify-tikv-config -n gc.max-write-bytes-per-sec -v xxxMB
(2)rocksdb 流控
参考 https://docs.pingcap.com/zh/tidb/v4.0/tidb-troubleshooting-map#43-客户端报-server-is-busy-错误 中 4.3.1 章节
(3)调低 pd 调度参数
store-limit 适当调小

1 Like

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