求教关于tikv磁盘损坏，缩容后扩容导致的 duplicated store address问题

[末0_0想]

【 TiDB 使用环境】测试

【 TiDB 版本】6.5
【复现路径】因磁盘损坏，本来三节点的tikv变成了两节点。后通过tiup cluster scale-in zdww-tidb --node 10.18.10.100:20160 --force 强制将tikv 进行移除。然后进行了缩容和扩容操作。为了降低异常，扩容节点配置，我使用了原有端口。后，我进行了 tiup cluster prune zdww-tidb 清理操作。

扩容后新的tikv节点一直处于 Offline状态。在进行启动时报以下异常
Error: failed to start tikv: failed to start: 10.18.10.100 tikv-20160.service, please check the instance’s log(/tidb-deploy/tikv-20160/log) for more detail.: timed out waiting for port 20160 to be started after 2m0s。

我查询tikv节点日志报:
[2023/03/30 19:15:58.377 +08:00] [FATAL] [server.rs:1099] [“failed to start node: Other("[components/pd_client/src/util.rs:878]: duplicated store address: id:31001 address:\"10.18.10.100:20160\" version:\"6.5.0\" peer_address:\"10.18.10.100\" status_address:\"10.18.10.100:20180\" git_hash:\"47b81680f75adc4b7200480cea5dbe46ae07c4b5\" start_timestamp:1680174958 deploy_path:\"/tidb-deploy/tikv-20160/bin\" , already registered by id:7 address:\"10.18.10.100:20160\" state:Offline version:\"6.5.0\" peer_address:\"10.18.10.100:20160\" status_address:\"10.18.10.100:20180\" git_hash:\"47b81680f75adc4b7200480cea5dbe46ae07c4b5\" start_timestamp:1678552849 deploy_path:\"/tidb-deploy/tikv-20160/bin\" last_heartbeat:1679019937896881375 node_state:Removing ")”]

查看了许多帖子说是要对pd的缓存进行清理。
tiup ctl:v6.5.0 pd -u http://10.18.100.162:2379 store
tiup ctl:v6.5.0 pd -u 10.18.100.164:2379 -i
store delete 7

尝试了很多次都不成功，执行store delete 7无法删除，或者说已经更新成最新的了， 故向各位求教下怎么处理。

【遇到的问题：问题现象及影响】

tikv 一直处于 Offline 状态。
tikv 启动时报有 duplicated store address 异常。

另外求教三个问题：
1、如果pd存在缓存配置，我该怎么清理。
2、tikv不是三副本吗，如果一个节点被重新加入数据会自动从其他节点同步过来吗？
3、我想请教下tikv是组成集群被pd调用 ，还是pd对三个tikv分别进行调用。网上信息比较杂，能提供个易懂点的帖子吗。

主控节点状态

tikv报错

tiup ctl:v6.5.0 pd -u http://10.10.100.162:2379 store

[h5n1]

pdctl store是否可以看到3001。原来的还没清理干净就又按原来地址的新增了，有冲突，先试着把原来的处理完。

offline状态就是store delete后的状态，在等待region迁移完成，如果仅有3台机器就先起另一个端口扩容一台tikv,扩容后观察原来offline store上region是否迁移完成，最后成为timbstone状态 之后执行prune . 如果过程中有问题 参考专栏 - TiKV缩容下线异常处理的三板斧 | TiDB 社区

关于几个问题

1. pd的region 信息是store通过心跳上报，如果不是tikv已经没region了，清理也没用
2. 节点正常工作会同步，但你现在的场景有冲突
3. pd是分配txn/region/store id,做region均衡，在tikv间调度region分布

[末0_0想]

你好！ 我按照您的说法在故障节点新建了端口，启动了tikv。但是原来offline状态的节点仍然没有状态变化。我观察了新节点的 REGION_COUNT 正在增加。但是旧节点有一直没有变化。

您发我的帖子我看了 ，因我对tidb了解不深。没有理解您手动调度迁移region的用意，请您方便的时候给具体说说。

在我理解，tikv必须三节点，如果有一节点损坏。pd分发会处于一种等待状态。直到加入新节点达到三节点后，pd会重新恢复三节点，这样pd分发才会正常。 但是这时损坏的节点怎么释放，pd中原来记录的tikv损坏节点记录怎么清理。 请指教。

[h5n1]

对你的理解是对的，可以等一段时间看看，或者先直接手动添加调度pd-ctl operate add remove-peer 把原来store的处理

[末0_0想]

谢谢 您的支持。 的确过了1天多时间tikv节点才从 offline 状态自动转化为 up 状态。 好像tikv 在恢复三节点后，自动同步了数据并把以前损坏的节点也重新修复变成了第四个节点。