【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】5.1.4
【复现路径】做过哪些操作出现的问题
【遇到的问题：
我们集群有40多个tikv节点，有一个tikv节点宕机了，进行下线操作，但是发现有一个region副本调度不到其他节点，通过pd直接手动move region之后，pd把副本调度到另一个正常tikv节点，但是状态一直是pending中，也就是不可用
发现这个region达到了惊人的200GB
coprocessor.region-split-size我们设置的是96M
尝试进行简单进行split region，会有超时报错
region调度后 region为pending状态 猜测是 region过大导致无法调度
从tikv日志看 也有在尝试split region 但是split有报错
gc是10分钟，由于gc压力比较大（删除比较多）所以gc清理几乎是一天才能清理一次
可以尝试一下手工compact
https://docs.pingcap.com/zh/tidb/stable/tikv-control#手动-compact-单个-tikv-的数据
另外这篇文章，你也可以看看。
可以尝试一下手工compact 的理由是什么呢，这个应该跟底层rocksdb compact不太关联？而且这个已经持续几天了，还是说怀疑有很多的tombstone
看这个
要看 Key 的删除是怎么操作的，如果是 delete 操作，那么没有 compaction 之前的 key 还是会扫到，除非是 drop/truncate table 会不用等 compaction。
目前已知的是：
1，你的gc已经跟不上了。原因不清楚，可能是你说的删除比较多，跑不完。也有可能是其他的原因卡住了（br，tispark，ticdc这些都有可能导致gc卡住），这个目前没有进一步信息提供。
最好是能看看tiup ctl:v{版本号} pd service-gc-safepoint的结果。
2,你自己也说了是删除比较多。可以肯定的是delete语句删除的空间，只有compact的时候才会回收。
所以综合两点来看，手工compact都是比较值得尝试的一个方向。
强制下线可以吗
之前有强制删除这个region过，但是在其他节点补副本的时候 依然有这个问题
从rocksdb的日志来看 ，节点是有compact的，不过我们可以业务低峰期手动触发一次compact看看
看看region 信息
tikv-ctl --host TIKV_IP:20160 region-properties -r REGION_ID
麻烦看下kv日志有什么报错信息吗？类似 panic这样的关键字
tikv-ctl --host TIKV_IP:20160 region-properties -r REGION_ID
手动触发compact有效果么？
没有效果呢，最后还是重新导出了这个表（还好表很小）然后rename了这个表，
也算是个解决方案了。记得给自己标记最佳答案。
