【 TiDB 使用环境`】生产环境 【 TiDB 版本】5.0.6 【遇到的问题】缩容一台TiFlash后显示tombstone，tiup prune无效果 【复现路径】 tiup cluster scale-in NAME111 --node X.X.X.X:9000 tiup cluster prune NAME111 【问题现象及影响】 prune之后还是显示node 状态为Tombstone，进入pd查看store也没有这个节点了，但是对此node节点执行scale-out还是提示port被占用（tiup edit-config配置文件中还有,也无法编辑掉） 【附件】 相关日志及监控（https://metricstool.pingcap.com/)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
scale-out Error: port conflict for ‘8234’ between ‘tiflash_servers:X.X.X.X.metrics_port’ and ‘tiflash_servers:X.X.X.X.metrics_port’
手动进入pd，store remove-tombstone 之后，tiup prune提示Error: no store matching address “X.X.X.X:3930” found
不知道你的操作环境和背景，不过一般都需要先解除掉 副本问题，然后在考虑缩容
具体的可以参考官方文档： https://docs.pingcap.com/zh/tidb/stable/scale-tidb-using-tiup#缩容-tiflash-节点
如果你需要强制缩容，也可以参考以上的内容来操作
有没有把TiFlash副本先清掉
总共有14个TiFlash节点，这个宕掉的节点已经很久了，我看了所有的副本都是2，小于节点数的。 操作步骤就是： 1、scale-in 2、这个时候变成了tombstone，然后prune 3、scale-out ，卡住失败 4、查询节点还是tombstone，再尝试prune无效 5、再尝试scale-in prune还是无效 ，状态还是timbstone 6、进入pd，store remove-tombstone，现在状态显示N/A
有14个TiFlash节点，这个宕掉的节点已经很久了，我看了所有的副本都是2，小于节点数的。 操作步骤就是： 1、scale-in 2、这个时候变成了tombstone，然后prune 3、scale-out ，卡住失败 4、查询节点还是tombstone，再尝试prune无效 5、再尝试scale-in prune还是无效 ，状态还是timbstone 6、进入pd，store remove-tombstone，现在状态显示N/A
不是副本小于节点数就可以了，要看副本数据在哪些节点上，不解除关系，仍然会有问题的
宕掉了，我理解副本会漂移吧，那现在咋处理合适？
手动edit-config删掉那个TiFlash节点无法保存
他这个是说所有的TiFlash节点下线吧，我这边是14个tiflash节点，宕了一个。 如果全下线再上线，业务估计会崩。
你这样查一下tiflash节点是否还有副本，没有的话可以–force强制缩容了
select p.region_id,p.peer_id,p.store_id,m.ADDRESS
from
TIKV_REGION_STATUS s
join TIKV_REGION_PEERS p
on s.region_id=p.region_id
join TIKV_STORE_STATUS m on m.store_id=p.store_id
where m.LABEL like '%tiflash%' and m.ADDRESS like '%tiflash_ip%'
这个TIKV_STORE_STATUS 里没有这个tiflash了，结果为空。按照–force强制缩容后现在可以了，谢谢！
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。