【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】机器重启 TiKV节点无法启动报错：
系统日志message里有oom：
后强制下线此TiKV节点，目前状态为offline
业务日志里有java.sql.SOLException: TiKV server is busy报错
查看PD日志：
[WARN] [cluster.go:607] [“store may not turn into Tombstone, there are no extra up node has enough space to accommodate the extra replica”] [store="id:5 address:"xxx:20160" state:Offline version:"3.0.16" "]
请问改如何强制下线这个tikv，或怎么修复这个集群（除了升级）
现在是几个tikv节点在跑？
看下集群状态呢，pd 还活着吗？
PD里不是说了嘛，没有足够空间去把下线节点的副本复制到其他节点，结合你的OOM，k
感觉象是空间不足引起的服务失败，从而拒绝服务
生产环境小心操作哦
–force 可以强制清除这种不可通信的节点
但是生产环境要考虑到安全之后处理
错误信息显示可能是由于磁盘空间不足或节点配置不合理导致的。你打开dashboard监控面板，看下各节点磁盘空间的剩余情况
display看看状态
一共4个 死了一个 目前还有三个在跑
活着呢
那扩磁盘就行？
磁盘空间够，内存也扩过了
这是3版本 没有dashboard 我看磁盘了是够的
你这个TiKV节点的Capacity size总容量是983GB，
Available size可用容量是422GB
也就是使用了983-422=561GB
那你其他的三个节点要消化掉这561GB数据吧
要是够用的话，就要排查其他地方了
看报错是磁盘读写权限出问题了。
Grafana上看下TIKV的面板吧 Cluster和Errors面板有啥异常没
那你或者扩容当前的3个活着的tikv节点的磁盘空间，或者扩容一个tikv节点，不然你坏掉的这个tikv上的region没有地方迁移，没法下线
哦，不过你这个版本太低了，现在都到7版本了
如果集群还是正常状态，这个offline的tikv节点是不是可以强制缩容？不过3.0的文档中没有关于强制缩容的方案，不知道直接执行步骤3是否可以。
不过，看报错信息，应该是在迁移数据，最好还是不要强制缩容了，先扩硬盘空间，看看能不能正常缩容下线吧。
store may not turn into Tombstone, there are no extra up node has enough space to accommodate the extra replica
