【 TiDB 使用环境】测试
【 TiDB 版本】v6.5.0
【复现路径】手动删除其中1个kv节点的存储路径：rm -rf /acdata/tidb-deploy/tikv-20163; rm -rf /acdata/tidb-data/tikv-20163
【遇到的问题：问题现象及影响】停止此节点kv服务，然后，进行缩容操作，使用如下命令：
# tiup cluster scale-in test-my-tidb-cluster --node 10.3.72.94:20163
然后，查检集群中此kv节点的状态，一直处于Pending Offline，无法回收。
【资源配置】
【附件：截图/日志/监控】
三副本 高可用集群， 3节点 ，挂了一个可以正常工作
嗯，是的，确实可以正常工作。现在，想把这个kv节点再恢复。先缩容，再扩容。结果，卡住不行了。使用–force强制清除后，再扩容就失败。
有时间，多看看官方文档， 您的 问题都能解决。
根据我画的重点。 准确的逻辑是：先扩容 ，再缩容 tikv 节点。
您的问题就是：缩容tikv节点， 低下的region因为无法找到 其他节点来保持三副本导致的。
您现在 能 扩容 一个新的 kv 节点不 ？
因为节点被手工删除了，所以要使用-force缩容才行。
扩容失败是报什么错？
先补节点，然后这个 Pending Offline的节点，会释放region，需要时间调度最后转换为 tombstone 的状态才能正常下线
3副本最少要3个tikv节点
能线扩容，就先扩容， 不能扩容 就 force吧
1、 3副本 3tikv ，只要没有>=2个tikv在同一主机上，其中一个随便任何方式挂掉都不影响tidb的可用性。
2、 3副本 3tikv ，想要正常缩容，玩不了，因为没有其他tikv节点接受缩容节点上的region，tidb绝对保证一个tikv只有region的一个副本，会一直处于Pending offline状态，处理方式就是再扩容1个tikv
3、 --force别随便用，那个只是从tiup里清理拓扑信息、清理部署目录，对缩容没任何帮助。
4、这个文档值的你读一读
pending offline 还在吗 ？？
看region_count
接下来，新扩容的这个kv节点，会不会同步复制另外2个kv节点上的副本，最终保持3副本状态。
目前来看，磁盘空间停留在18G，不动了。
# df -h|grep acdata
/dev/mapper/acvg-lv_data 493G 18G 450G 4% /acdata
pending offline不在了，我使用–force参数，强制清除了。
上去PD 看看 store 还在不 ？？