tiup prune无效果

【 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

你按这个文档用手动缩容试试

https://docs.pingcap.com/zh/tidb/stable/scale-tidb-using-tiup#方案二手动缩容-tiflash-节点

不是副本小于节点数就可以了,要看副本数据在哪些节点上,不解除关系,仍然会有问题的

宕掉了,我理解副本会漂移吧,那现在咋处理合适?

pd里面已经删除了 视图里面也找不到了

但是tiup cluster display还是N/A状态

手动edit-config删掉那个TiFlash节点无法保存

按图上的操作搞了

  1. 先整理规则
  2. 该清理就清理下,然后在执行手动删除的步骤
  3. 如果第二步执行之后还不行,我建议关闭所有的同步规则,将所有的 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强制缩容后现在可以了,谢谢!