【 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)
问题：这种情况下，stop tidb集群，再做unsafe recover，是否会有其它未知的风险呢？
1 个赞
网络没有问题，有一个storeid=5的，之前宿主机硬盘维护，重新加入进来的时候，id变成了一个而很大的id指，store delete 5 基本无效，有留存的store id=5信息的region无法读取，因为region leader为null了。
gc出问题的region里面，也包含了store id=5的信息。
我的问题是问题：这种情况下，集群gc失败，容量未减少，但是drop了百分之98的表，stop tidb集群，再做unsafe recover，是否会有其它未知的风险呢？
1 个赞
unsafe recover 的目的是修坏的 region 么 ？如果这个情况下，执行 unsafe recover 是没有问题。不过要注意，如果执行的 unsfe recover remote store 以后，这个节点确认已经下线，不会重新加入到 TiDB集群里面。否嘴对线上数据破坏很严重。
1 个赞
节点都没有下线，都会重新加入tidb集群，目前有95个tikv节点有 store id=5的region，都需要进行unsafe recover，这种情况，你帮忙看看呢？
1 个赞
dbaspace
(dbaspace)
7
之前线上那么干，出现过问题，会导致一些数据的异常的，最好是停止，可能在你unsafe发生REGION分裂 会异常，后面还要修复等问题
1 个赞
你好，你说的是停止tidb整个集群 嘛？然后进行unsafe recover ？
Meditator
(Wendywong020)
10
1 个赞
谢谢，不过这个版本太新了，v5.2.1，我的才是v3.0.3呢。
system
(system)
关闭
15
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。