测试3节点tikv,手动删除其中一个tikv-server的数据目录,之后恢复这个节点

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
tikv版本5.2.0,没使用tidb,只部署了3节点tikv+1pd

【概述】 场景 + 问题概述
尝试模拟坏盘或者误删文件导致tikv-server故障

【问题】 当前遇到的问题
1、集群正常情况下,直接暴力删除/tikv/tidb-data/tikv-20162数据目录
删除后该节点很块进入disconnect状态
2、强制scale-in该节点,使用tiup cluster scale-in tikv-cas-test --node 172.16.31.148:20162 --force
提示会删除数据,确认删除后,tiup cluster display tikv-cas-test 已经看不到对应的节点
3、重新scale-out该节点
该节点一直处于Offline状态,看到20162这个节点的日志一直报 duplicated store

4、按照其他贴子说是pd信息没清理要执行设置节点为tombstone

这种节点已经故障的情况下如何让节点重新初始化进入集群?

1赞

知道怎么回事了,集群只有3个节点的情况下,下线故障节点状态永远不会变成Tombstone,因为要保证3副本再不同的host上,所以不会迁移region,这种情况下需要先增加一个节点,让region迁移过去,再处理下线操作

3赞

执行过清理么?我遇到过类似的问题,缩容下线节点过程中,还没有变成墓碑,就手工删除节点数据,然后在相同端口相同位置扩容节点,结果扩容之后还是在执行缩容均衡region,实际数据文件已经删除。

1赞

我是先让节点异常,处于disconnected状态,然后scale-in,由于只有3节点,状态应该变不了tombstone,一直再Pending offline状态,在执行scale-in --force,这时候pd的数据信息应该是没清理,此时相同的端口和位置scale-out肯定是不成功的,后来我在不同的端口和位置新增一个tikv-server,状态很块就切换到正常了

1赞

:+1::+1::+1:感谢分享

1赞