原文来源：https://tidb.net/blog/81a942af

社区里很多大佬总结了多副本丢失的灾难恢复方法，但是平时遇到最多的单节点故障快速恢复还没有人总结，本文为亲身实践后总结的问题处理过程，此过程保持集群可用无需停止其他节点服务。

背景

故事发生在炎炎夏日的某一天，通过一系列磁盘的 iops 的测试后，发了个工单质疑阿里云的 ESSD 磁盘性能不达标，阿里云的客服给我发了一份他们的测试文档，我在某个 tidb 集群上就开始测试，等我测试完后发现 vdb 的分区没了。

测试文档中提示，有可能会造成文件系统损坏。

tidb、pd、tikv 是混合部署在一起的，TIDB 集群变成了如下状态，得益于 TIDB 强大可用性设计，这个时候集群还是可用状态。

修复

最快速的修复办法是直接增加一台服务器扩容 down 掉的节点然后缩掉有问题的节点、回收服务器，但是为了节约资源，决定在原服务器上缩容扩容节点。

首先强制缩掉三个 down 掉节点：

tiup cluster scale-in tsp-prod-taos-cluster –node 10.20.10.138:4000 –force

tiup cluster scale-in tsp-prod-taos-cluster –node 10.20.10.138:2379 –force

tiup cluster scale-in tsp-prod-taos-cluster –node 10.20.10.138:20160 –force

集群变成如下状态：

重新给 138 服务器格式化 vdb 分区

在 138 服务器上扩容 tidb、pd、tikv 节点

tiup cluster scale-out tsp-prod-taos-cluster ./topo-kv02-tidb02-pd02.yaml –user root -p

global:  user: "tidb"  ssh_port: 22  deploy_dir: "/data/tidb-deploy"  data_dir: "/data/tidb-data"
server_configs:tikv_servers: - host: 10.20.10.138   port: 20160   status_port: 20180pd_servers: - host: 10.20.10.138tidb_servers: - host: 10.20.10.138

tidb 和 pd 启动成功，kv 启动失败

以下是报错日志：

Error: failed to start tikv: failed to start: 10.20.10.138 tikv-20160.service, please check the instance's log(/data/tidb-deploy/tikv-20160/log) for more detail.: timed out waiting for port 20160 to be started after 2m0s

[2023/08/09 10:37:25.985 +08:00] [ERROR] [util.rs:475] ["request failed"] [err_code=KV:PD:gRPC] [err="Grpc(RpcFailure(RpcStatus { code: 2-UNKNOWN, message: \"duplicated store address: id:406981 address:\\\"10.20.10.138:20160\\\" version:\\\"5.4.3\\\" status_address:\\\"10.20.10.138:20180\\\" git_hash:\\\"deb149e42d97743349277ff8741f5cb9ae1c027d\\\" start_timestamp:1691548641 deploy_path:\\\"/data/tidb-deploy/tikv-20160/bin\\\" , already registered by id:4 address:\\\"10.20.10.138:20160\\\" state:Offline version:\\\"5.4.3\\\" status_address:\\\"10.20.10.138:20180\\\" git_hash:\\\"deb149e42d97743349277ff8741f5cb9ae1c027d\\\" start_timestamp:1679983970 deploy_path:\\\"/data/tidb-deploy/tikv-20160/bin\\\" last_heartbeat:1689209409692065070 \", details: [] }))"]

通过 pd-ctl 查看 store 4 处于 offline 状态，新的 kv 节点无法在 pd 中注册。

尝试删除 store 4, 虽然显示成功了，实际上并没有删除。

原因是：delete 成功，触发整个 store 下线（offline）、开始 region 迁移，在正常情况下，这个 store 所有 region 迁走后会变成 tombstone 状态。但是实际上这个 store 上 region 没有发生迁移（有效 tikv 数小于 replica 数）。

尝试设置该 store 状态为 Tombstone，设置失败。

curl -X POST http://0.0.0.0:2379/pd/api/v1/store/4/state?state=Tombstone

原因是在 5.0 及以上版本中，该接口只支持更改 state 为 Up 或者 Offline，废弃了直接更改为 Tombstone 这个功能。这是由于直接更改为 Tombstone 总是引起操作者意料之外的结果。

把 store 4 的 physically_destroyed 设置成 ture

curl -X DELETE http://0.0.0.0:2379/pd/api/v1/store/4?force=true

再看 store 状态

138 新的 kv 节点也自动注册上来了

pd 开始调度 region 到 138 新加入的 kv 中。

这个时候在 pd 中查看还是有 4 个 store，由于有效 tikv 数 >=replica 数，region 在迁移减少了。

适当调大 region 调度速度

region 迁移结束，pd 中 sotre4 消失

至此修复全部完成！

总结：

1 本文比较基础，提供了简单的处理流程，适合帮助对 tidb 理解不够深入的新手。

2 没事别瞎折腾服务器，另外需要吐槽下阿里云的 ESSD 磁盘性能是真的不行，测试下来大概只有 nvme 物理盘的五分之一。

3 遇到误删文件不要慌，无论是丢失少数副本无损修复还是丢失大多数副本有损修复，TIDB 社区都有成熟案例和方案供大家选择。