tikv磁盘存储数据一直异常增加

[Hacker_UBVfs1Zv (None)]

能不能再我已经给的信息中给解决

[h5n1]

你再看下报错中的key ，多找几个 ，在information_schema.tikv_region_status根据start_key end_key 确认下这个key所属的region_id， 然后pd-ctl region xxx 看下这个region的信息

[WalterWj (王军 - PingCAP)]

其实有一个简单解决方法，那就是你逻辑备份重建一个集群肯定没问题了。

或者再试试 recover 能否自我修复，使用类似：auto detect：

tiup ctl:${cluster_version} pd -u http://${pd_conn} unsafe remove-failed-stores --auto-detect

[Hacker_UBVfs1Zv (None)]

重建集群代价太大了，影响业务，这个生产在用。
–auto-detect这个命令使用了，tikv还是有

异常的日志

[Hacker_UBVfs1Zv (None)]

找了十几个startkey，对应的region没找到

[h5n1]

找到的key between start_key and end_key。 你看下key的大小写

[Hacker_UBVfs1Zv (None)]

这个auto-delect这个命令有用，空的region在删除了。现在磁盘空间下降了一部分

[WalterWj (王军 - PingCAP)]

好的，unsafe recover 后续一定要慎用、慎用、慎用。

unsafe recover 命令最好在官方判断下使用，这个是强行清理相关节点数据的命令。这个一旦敲下去，集群就很有可能丢数据。

[Hacker_UBVfs1Zv (None)]

就是不确定这个GC是否后续还会不会卡住

[WalterWj (王军 - PingCAP)]

你先观察一段时间吧。不一定。

[tidb狂热爱好者]

学到了一招

[FutureDB]

这个看下来都可以作为一个故障排除的经典案例了

[Hacker_xUwtuKxa]

请问：空洞 region是什么意思呢？一般什么情况下会产生空洞region呢?

但总觉得即便这个空间降下来了，集群状态还是有问题，从日志中看到：访问pd一直报错。
我觉得比较稳妥的做法是新建一个集群，然后dumpling+lighting+binlog将数据同步到新集群，然后找个时间生产切换到新集群，<1TB的集群，1小时内能完成，若应用不接受那么长的停机维护，加上binlog同步，几分钟的应用切换，能搞定。

[Hacker_UBVfs1Zv (None)]

这样成本太高，需要一个新的集群，切换还会影响业务