1.tikv缩容后，tiup状态一直处于 Pending Offline 状态，命令操作如下：

tiup cluster scale-in tidb-cluster --node ip:20160

2.通过命令 tiup cluster display 集群名字，找到pd

通过命令可以看到对应节点的store状态是offline，region_count和used_size没有减少，tiup ctl:v5.0.1 pd -u http://10.33.2.43:2379 store，下面的store id是1

二、排查思路

1.先检查环境，tikv的副本因为默认是3个，所以存活的tikv节点不能少于3个，例如只有3个tikv，现在要下线一个，那数据是不会迁移的，需要扩容tikc后才会进行数据迁移操作。

2.下线的tikv中数据需要迁移到其他tikv上，那首先确认其他tikv目录容量是否够，这个手动检查下加上查看pd的日志可以看到哪个节点的容量不够，正常目录使用超过80%就迁不过去了。

3.tikv是上报存活到pd上的，如果pd重启后tikv最好也重启下，连接不上pd的话tikv最好重启下，命令如下.其他节点也是这样重启，这里网络如果出现问题也会导致这个问题，tikv的迁移tikv和pd的日志都会有输出，重点看下日志也没有报错。

4.有些迁移很慢，这里看下tidb-grafana的监控，着重看以下几个，pd视图下-Operator下的“Schedule operator create”（创建任务）， ”Schedule operator finish“（任务完成），迁移就会有创建任务，

那如何提高这个创建任务的并发数量，调度的操作全靠pd，所以限制的开关就在pd上面，操作如下：

“max-pending-peer-count”: 16, #reginon同时下线的并发量

#这里说明下，tikv下线主要就是region迁移，所以就靠2个参数，调大就能增快速度。