前期TIDB 部署架构：
**【概述】：
环境为测试使用资源：如图 TIFLASH 节点已经剔除; 替换添加 TIKV 节点（总计4个节点）
因近期硬件资源紧张，准备剔除 一个 TIKV 节点;
使用命令后发现 节点状态一直为 Pending Offline;
之后以为是该节点有问题，故再次剔除一个 发现一样状态
查看了 论坛上 也不是 空间已满的情况：
如果使用强制下线，是不是会影响库内数据？
首先要保持到 3 个 tikv 节点，然后才能满足调度的需求
另外下线后， Pending Offline 状态是正常的，下线的节点会把leader region 传递出去，给到其他的节点来接收
这个过程是需要时间的，另外如果觉得转移太慢的话，可以调整 region 迁移参数
leader-schedule-limit ：控制 Transfer Leader 调度的并发数下面的参数是用来快速同步副本的
replica-schedule-limit最好提前驱逐节点：
>> scheduler add evict-leader-scheduler 1
// 把 store 1 上的所有 Region 的 leader 从 store 1 调度出去
你好 ，节点是我昨天下午的时候 开始缩容的，到了今晚下班的时候发现还是之前状态，一直没变化，刚刚已经强制下线了，重新加入 集群 扩容，发现 PD 里面的之前信息没删除，导致无法注册 PD 与 启动！！
TIDB 集群 可以 配置 2个节点不 ？ 或者把 三副本 改 两副本 ？ 不过 我记得貌似 官方那边说过 集群最低就是 三副本 
tikv 最少 三节点，而且必须三副本…
强制下线，会导致集群中存在异常信息，如果数据没丢的话，用 pd-cli 强制删除吧
这个只是测试环境，没上生产。。 想问一下 在只有3个节点的情况下， 如何把 下线的其中一个节点 重新上线呢 ？
官方有文档吗 ？
好的，多谢了！！
这种情况是正常的。参考官方文档：
由于 TiKV，TiFlash 和 TiDB Binlog 组件的下线是异步的（需要先通过 API 执行移除操作）并且下线过程耗时较长（需要持续观察节点是否已经下线成功），所以对 TiKV，TiFlash 和 TiDB Binlog 组件做了特殊处理：
- 对 TiKV，TiFlash 及 TiDB Binlog 组件的操作:
- tiup-cluster 通过 API 将其下线后直接退出而不等待下线完成
- 执行
tiup cluster display查看下线节点的状态，等待其状态变为 Tombstone- 执行
tiup cluster prune命令清理 Tombstone 节点，该命令会执行以下操作：
- 停止已经下线掉的节点的服务
- 清理已经下线掉的节点的相关数据文件
- 更新集群的拓扑，移除已经下线掉的节点
- 对其他组件的操作
- 下线 PD 组件时，会通过 API 将指定节点从集群中删除掉（这个过程很快），然后停掉指定 PD 的服务并且清除该节点的相关数据文件
- 下线其他组件时，直接停止并且清除节点的相关数据文件
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
