【 TiDB 使用环境】生产环境
【 TiDB 版本】V7.5.0
【复现路径】对同一台服务器缩容再扩容后执行了 curl -X DELETE http://136.18.1.6:2379/pd/api/v1/store/4?force=true（参考某大神的 专栏 - TIKV节点数据文件误删后不更换服务器快速恢复 | TiDB 社区）
【遇到的问题：问题现象及影响】现在一共有4个store，被缩容的store一直是Offline状态，一直没被删除，然后tikv.log中频繁出现两个error日志，如下图所示
【附件：截图/日志/监控】
你一共三个tikv怎么先缩容再扩容啊？你先找台其他的机器，或者原机器上换个端口扩容个tikv节点，然后再缩容啊。。。。
同一个节点缩容再扩容进去有啥意义呢 
？，3 副本 3 个节点正常缩容是缩不下去的，不了解 TiDB 原理，不建议做什么强制缩容等危险操作，否则容易把集群搞坏
咋办呀我现在，我是强制缩容的 然后再扩容
pd-ctl 执行下 store 命令，再把监控 PD=》Statistics - balance=》Store leader count 和 Store region count 面板截图看下
在扩一个就好了
还是我上面的建议，你先找台其他的机器，或者原机器上换个端口扩容个tikv节点，然后再缩容这个异常的节点吧
谢谢老师，我重新再其他机器上扩容了一台，缩容异常的tikv后状态一直为Pending Offline
你再看下这个store的信息，看看region和leader的数量是否再减少
老师你好，是有慢慢在减少但是比较慢
是leader_count和region_count吗
谢谢老师我先尝试下上面老师的方式，谢谢您 我是一个初学者遇到些问题请教，您们能无偿帮助给出建议真的非常感谢 
是生产坏境？使用接口地址操作，艺高胆大。新扩容的数据平衡后，再观察下。之前缩容操作未完成（终止）和又扩容的动作，数据也很大，估计得耐心等等。
今天在检查数据库的时候发现kv日志一直报错无法写入消息了，排查发现这台kv的磁盘有问题就网上找了个方法看着挺靠谱的没想到风险这么大，还好有大神和老师们帮助，谢谢您们，祝您们工作顺利 升职加薪，谢谢您的回复
还好这个系统是今晚00点上线，还有一点补救的机会 
您好我又发现个问题，我新扩容的kv数据目录只有250G空间，但是我看其他两台kv已经使用到了300多G
可以考虑再扩容一个节点来分摊存储压力。后期还是要吧每个节点的磁盘空间调大一点。250G的硬盘空间太少了。
明白了老师，这个250G的只是作为一个过度，等待异常的kv服务器缩容完成后，我可以重新在 在这个异常过的kv服务器上再扩容吗，然后把250G的这台kv缩容
可以的，重新扩容就是一个新的节点了。
