TiKV server timeout[try again later]

  • 系统版本 & kernel 版本】centos7.5
  • TiDB 版本】2.1.16
  • 集群节点分布】 57 pd/db/kv 56 pd/db 55 pd/db 81 kv 83 kv
  • 数据量 & region 数量 & 副本数】 数据量1T,region 7.7W
  • 问题描述(我做了什么)】 昨天kv节点down掉2个,通过unsafe-recover操作恢复,并扩容了2个kv节点,现在数据库查询单条语句,比如:select * from t1 limit 1比较慢,但是还是能够返回结果,但是使用count(*)就报TiKV server timeout。请各位大佬帮忙看看。

原来是三个 TiKV , 昨天 down 掉两台后,进行了恢复,并又重新扩容了两台,现在正常的 TiKV 应该是 5 台? 使用 pd-ctl -u http://pd:2379 -d store 看下现在是否有离线的 store

那两台是缩容了,那两台上还有一些region一直无法调度

其中1247796,291417这2个store的region一直没变,1292176的region补副本很慢。

在tidb日志中还有很多Region is unavailable[try again later]错误

请仔细查看文档,

  1. 缩容要等状态变成 Tombstone 状态才能把它们停掉
  2. 另外原本只有 3 个 TiKV ,你再缩容肯定有问题,应该先扩容再缩容

那两个下线的 TiKV 你是停掉了吗,停掉了的话,启动一下,或者重启一下集群。 现在看起来就是这两台上的 region peer 有丢失。

一开始有4个tikv节点,分别是55,56,57,83 7号凌晨4点50,down掉2个tikv,分别是55,56。查看日志发现tikv不停的报错重启,然后我delete掉store,等了大概3个小时,发现delete的节点region一直没有变化,tikv还是不停的再报错重启。然后我通过unsafe-recover去掉了那2个节点,重新扩容了2个tikv节点81,82。 7号晚上19点,发现又有一个tikv不停的报错重启,状态和55,56一样。然后我继续通过unsafe-recover操作去掉了这个节点。现在节点就是57,81,83,到了8号中午83节点也不停的报错重启,这次没有通过unsafe-recover操作,我delete掉这个节点,发现region不调度,然后通过改端口再83节点又起了一个tikv节点,发现磁盘空间不够,我删掉了整个83节点上的tidb目录,重启了一个tikv节点,然后通过unsafe-recover操作去掉了原来再83上的store,现在tikv日志不再报错,但是就是返回超时和region不可用。 老师可以看一下这个帖子https://asktug.com/t/tikv-down/1673/29

这是整个事件的经过,一开始tikv挂掉,现在报错信息不一样,我就重新开了一个帖子。

看下 pd leader 日志,或者 PD 监控 - operator 中看看 Schedule operator create 和 Schedule operator finish

老师这种情况已经造成集群无法提供服务了,我能将数据备份下来重新搭建集群吗,我想这样会快一些。 但是用mydumper备份报错。老师有没有其他的方式保证数据不丢啊,真的很急啊。麻烦老师了

这个节点leader数量4289也不再增加了,其他2个节点有20K左右

pd-ctl config show all 也贴一下

config.txt (2.7 KB)

pd-ctl region --jq=".regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length != 3)}" 看下这个结果

非常多,这个图只是一部分,要一起发给你吗?

35863个

麻烦把 pd 的监控导出成 pdf 发我一份吧

tidb-cluster-pd.pdf (2.0 MB)

» region --jq=".regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(291417,1247796) then . else empty end) | length>=$total-length) }"