【是否原创】是
【首发渠道】TiDB 社区
【目录】
一、现象
二、排查思路
【正文】
一、现象
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的日志都会有输出，重点看下日志也没有报错。
tiup cluster restart tidb-zabbix --node tikv:port
4.有些迁移很慢，这里看下tidb-grafana的监控，着重看以下几个，pd视图下-Operator下的“Schedule operator create”（创建任务）， ”Schedule operator finish“（任务完成），迁移就会有创建任务，
那如何提高这个创建任务的并发数量，调度的操作全靠pd，所以限制的开关就在pd上面，操作如下：
tiup ctl:v5.0.1 pd -u http://10.33.2.43:2379 -i; #进入交互界面
config show; #重点看2个参数就可以了
“max-pending-peer-count”: 16, #reginon同时下线的并发量
“region-schedule-limit”: 16, #region调度的数量
#设置参数如下，config set 参数 值
config set region-schedule-limit 16
#这里说明下，tikv下线主要就是region迁移，所以就靠2个参数，调大就能增快速度。
#以上就是我多次下线tikv碰到的问题和处理心得，希望对大家有用