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

背景

故事发生在炎炎夏日的某一天，通过一系列磁盘的iops的测试后，发了个工单质疑***的E***磁盘性能不达标，***的客服给我发了一份他们的测试文档，我在某个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: 20180 pd_servers: - host: 10.20.10.138 tidb_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 instances 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:2 0160\\\" 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 de ploy_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 没事别瞎折腾服务器，另外需要吐槽下***的E***磁盘性能是真的不行，测试下来大概只有nvme物理盘的五分之一。

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