pd无法恢复快照

对于PD无法恢复快照的问题，通常有以下几种原因：

1、PD文件系统损坏：PD文件系统可能会受到损坏，这将导致无法恢复快照。

2、PD快照损坏：PD快照可能被损坏，这将导致无法恢复快照。

3、硬件问题：如硬盘故障，硬件驱动器故障等，都会导致PD无法恢复快照。

4、 *** 作系统错误：如 *** 作系统被损坏，病毒感染等，都会导致PD无法恢复快照。

5、系统不兼容：如恢复快照的系统和当前系统不兼容，也会导致PD无法恢复快照。

通常情况下，如果PD无法恢复快照，可以尝试以上几种方式解决，如果仍然无法解决，可以尝试联系PD技术支持人员，由他们来帮助您解决PD无法恢复快照的问题。

下面是本次测试环境服务器的概况，一共四台机，其中三个KV。按照默认的副本数，一共有三个，也就是说可以允许我的KV能挂掉一个而不影响业务。下面我们来测试一下三种的情况：

我们的测试方法很简单，首先新建一个测试表并插入数据；然后直接kill掉kv的进程，模拟宕机；然后再登录TiDB看下数据是否还在，能否做插入、删除的 *** 作。

select查询确认数据

这时候我们看grafana的tv监控页面，看到leader的分布是很不均匀的，这里我们不探讨。下面我们把tikv_2给kill了看下。

在这里我们要kill的是tikv_2，这里刚好对应的是我的tikv主机IP较小的那个（192.168.113.21）

这样kill掉之后，很快tikv会自己重启启动的，这样的没办法很好地测试的。所以干脆，我直接把tikv_1的服务器给shutdown了，看下是什么样的一个情况。

在grafana的监控面板上我们可以看到有一个tikv down了，还有该服务器上的探测器。

我们看下tikv的leader的情况，可以看到已经有部分的leader转移到tikv_1和tikv_7上了，我们看下那个测试表的数据。

在挂了一个kv的情况下，还是可以正常地插入和删除数据的，也就是说TIDB还是正常运作的。

测试结束后我们开启虚拟机，并重新把tikv01上的tikv的服务打开。

启动后我们还发现了kv的leader并没有转移回给tikv_2上，leader的分布还是很不均匀。

这里我们新增一个kv，新增的一个虚拟机的配置情况如下

使用ansible来初始化并部署tikv

几分钟后我们就可以在grafana上看到新增的tikv实例了，我们看下他的实例名称，以及leader和regions的数量。

从上图我们可以看到新增的tikv的实例叫做tikv_2006，并且已经有region转移到这个实例上了，但是分布还是不均匀，我们等待一段时间看下。

半个钟之后，发现tikv_2006还只是获得6个region。这个问题我们后续再讨论，这里继续下面的缩容实验。

现在我们有4个Tikv了，下面我们缩容一个，只保留三个。我们对实例名为tikv_1也就是192.168.113.22这台服务器下手吧，缩容的过程也命令非常简单。

查看 192.168.113.22节点的 store id，查询到的store id为1，也就是tikv_1，这就是它的实例名称。

从集群移除store id 为 1的tikv：

使用 Grafana 或者 pd-ctl 检查节点是否下线成功（下线需要一定时间，下线节点的状态变为 Tombstone 就说明下线成功了,这个时间可能非常久）：

等待了几分钟，下线成功。

下线成功后，停止192.168.113.22 上的服务，没下线成功请不要进行下面的 *** 作，耐心等待。

编辑 inventory.ini 文件，移除节点信息：

更新 Prometheus 配置并重启：

打开浏览器访问监控平台：http://192.168.113.20:3000，监控整个集群的状态。

在进行tikv的缩容后，grafana的页面上会出现墓碑状态数量为1的情况。在确认下线之后，我们还要处理这个监控，否则这里会干扰我们监控的准确性。一是这个状态很碍眼，明明我都下线成功了为什么这个状态还没有消除；二是 Leader balance 和 Region Balance的判断把墓碑状态的实例数据也算进去，导致这个数据一直都是100%。

去除这个监控数据的关键在于如何删除pd上的墓碑节点，在旧版本（2.1.17及3.0.0版本）中，这样的节点没办法删除的，在新版本中我们可以使用pd-ctl工具进行删除。

就这样我们就可以把墓碑状态的节点删除了，但是删除后 Leader balance和 Region Balance还没有恢复正常，在prometheus中还是监控到墓碑节点的数据，最后重启pd（生产环境下慎用）解决。

---