本次出故障的是我们的测试环境，因为前期搭建控制成本，整个集群只用了 1个PD、1个TiDB、3个TiKV，属于是极简中的极简。

而昨天刚好我们的宿主机因为磁盘损坏导致整个物理机数据全部丢失，其下的一系列虚拟机通通无法恢复，而恰是我们的PD节点，这就导致了集群现在一个PD节点都没有了。

幸运的是所有TiKV节点服务都还在，并且接近过年业务已经没有使用。经过查询官方文档和询问官方专家，这种情况确定可以恢复，下面开始恢复流程。

集群信息

服务器版本： centos7.9

TiDB版本： V5.4.0

拓扑信息：


PD	172.20.3.102
TiDB	172.20.3.101
TiKV	172.20.3.103 172.20.3.104 172.20.3.105
monitoring_servers	172.20.3.102
grafana_servers	172.20.3.102
alertmanager_servers	172.20.3.102

恢复过程

1. 前期准备

在确认好 172.20.3.102 信息后，联系IT进行了对应配置的虚拟机生成，现在得到一个新的centos7，地址为 172.20.4.100

得到服务器后开始操作部署前的准备工作，这里可以按照原集群的部署文档操作，也可参考官方文档https://pingkai.cn/docs/tidb/stable/check-before-deployment/

2. 找到cluster_id和最大的alloc-id

参考文档：https://pingkai.cn/docs/tidb/stable/pd-recover/#%E6%96%B9%E5%BC%8F%E4%BA%8C%E5%AE%8C%E5%85%A8%E9%87%8D%E5%BB%BA-pd-%E9%9B%86%E7%BE%A4

cluster_id

因为PD节点整个服务器已经没有了，所以现在到TiKV上的日志来查找，顺利得到了集群的cluster_id

grep "connect to PD cluster" tikv.log

alloc-id

按照官方文档的提示，最大的已分配id可以从监控面板获取，但现在PD节点已经不存在了，所以只能从TiKV日志中找最大的 Raft Log Index ，然后再在这个id的基础上加上一些作为安全的的alloc-id。

选择Raft Log Index的原因是：TiKV 在 apply Raft log 时会记录日志，其中 index= 字段就是 Raft Log Index，它是由 PD 全局分配的，单调递增，可作为 alloc-id 的参考。

获取脚本

# 在 所有TiKV节点上分别运行，再取最大值
grep -oE 'index=[0-9]+' /data1/tidb-deploy/tikv-*/log/tikv.log | \
    cut -d'=' -f2 | \
    sort -n | \
    tail -1

3. 部署集群

服务器前期工作准备好以后，现在开始部署新的集群，部署yaml文档如下

这里的注意点是剔除无法恢复的原PD节点，将新的PD节点加入

global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/data1/tidb-deploy"
  data_dir: "/data1/tidb-data"

pd_servers:
  - host: 172.20.4.100

tidb_servers:
  - host: 172.20.3.101

tikv_servers:
  - host: 172.20.3.103
  - host: 172.20.3.104
  - host: 172.20.3.105

monitoring_servers:
  - host: 172.20.4.100

grafana_servers:
  - host: 172.20.4.100

alertmanager_servers:
  - host: 172.20.4.100

确认信息无误后开始在4.100上部署新的集群

tiup cluster deploy tidb-test v5.4.0 ./topology.yaml --user root

部署完成后提示启动服务，不过我们这里不是新建集群，所以去掉了 --init 参数

tiup cluster start tidb-test

集群顺利启动，现在查看集群状态

tiup cluster display tidb-test

3个TiKV为down的结果是预期内的，因为还没识别到新的PD。

4. 恢复集群

开始使用 pd-recover 工具进行PD的恢复

tiup pd-recover -endpoints http://172.20.4.100:2379 -cluster-id 7166938305067148765 -alloc-id 10000

因为当时恢复是没有搞清楚alloc-id的含义，所以直接使用了官网的参考值，所幸恢复提示成功并且后续正常启动了

在重启过程中持续观察TiDB集群的状态

tiup cluster display tidb-test

5. 验证数据

再确认重启完成并且集群状态正常后，开始连接数据库验证数据是否正确，读写是否正常。

验证结果都正常，本次恢复顺利完成。

总结

本次过程难度比较低，不过官方文档步骤较为简略所以多用了些时间研究步骤。整体的恢复过程还是相当顺利，而给到我们的警示还是就算测试环境也应该至少运行3个PD，不要为了极致的成本造成可能丢失全部数据的局面。

记录一次PD服务全挂，利用pd-revocer恢复的过程