执行unsafe recover操作返回信息有问题

🪐 TiDB 技术问题
1

【 TiDB 使用环境】 类似冗余日志数据使用场景
【概述】准备操作unsafe recover
【背景】迁移数据后，drop原表，按照库表的数量，只剩下1/20的迁移不动报错的分表了；但是tikv节点磁盘空间一直没有释放，监控图容量还是330T+，看后台gc的tidb节点，好多报错信息：
[INFO] [client_batch.go:525] [“recycle idle connection”] [target=172.xx.xxx.xxx:20160]
[ERROR] [client_batch.go:278] [“batchRecvLoop error when receive”][target=172.xx.xxx.xx:20160] [error=“rpc error: code = Unavailable desc = transport is closing”] [stack=“github.com/pingcap/tidb/store/tikv.(*batchCommandsClient.batchRecvLoop
\t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client_batch.go:278”]
【现象】grafra监控显示集群容量还是300T+
【TiDB 版本】Server version: 5.7.25-TiDB-v3.0.3 MySQL Community Server (Apache License 2.0)

这是之前的记录信息，今天进行了/data0/tidb/tikv-ctl --db /path/to/tikv/db unsafe-recover remove-fail-stores -s 22 --all-regions操作，操作之前已经stop tidb集群，但是却没有按照文档https://docs.pingcap.com/zh/tidb/v3.0/tikv-control/#强制-region-从多副本失败状态恢复服务中的提示返回sucess，而是返回的信息是：
removing stores [22] from configrations…
Debugger::remove_fail_stores: “Store 22 in the failed list”
之后tikv-ctl 进程就结束退出了。

image
image821×409 22.8 KB

1 个赞
2

之前的帖子记录地址是：https://asktug.com/t/topic/243248，现在有执行过unsafe recover的朋友嘛？帮忙看看问题

1 个赞
3

通过 pd-ctl 查询一下 store id 为 22 的 store 的状态

1 个赞
4

解决了吗

5

store 22，状态是：
“state_name”: “Up”

1 个赞
6

unsafe-recover remove-fail-stores -s 这个操作是 -s 是故障 store id ，不是正常的 store 节点。论坛里面有其他的 sop 文档可以搜索参考一下。
https://docs.pingcap.com/zh/tidb/stable/tikv-control/#强制-region-从多副本失败状态恢复服务慎用

2 个赞
7

330T+，好大的库，多少个tikv实例

1 个赞
8

谢谢提示：
1，我这边版本是3.0.5，不是5.4，我看的文档是：强制 Region 从多副本失败状态恢复服务：https://docs.pingcap.com/zh/tidb/v3.0/tikv-control#强制-region-从多副本失败状态恢复服务

2，只有1个坏的tikv，storeid=5，但是是磁盘故障了，里面数据全部没了，重新加入后storeid=39124701，不是之前报错的5了。

帮忙看看这种情况，怎么处理？

9

上百个

10

未解决

11

那 -s 应该写的是 -s 5 不是 -s 22

12

@TiDBer_uwVlus4v 别着急操作,先把这个 sop 文档读两遍,理解一下操作的方法.可以在测试环境尝试一下,然后再生产操作.【SOP 系列 18】TiUP 环境恢复 TiKV 副本

13

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