TIDB灾难恢复演练三部曲（中）

小编介绍

大家好，我是本际云服务器推荐网的小编小本本，今天为大家带来TIDB灾难恢复演练三部曲的第二部分内容。

TIDB灾难恢复演练三部曲（中）

两个副本丢失情况下的测试

在上一部分我们开始了对两个副本丢失的演练。当宕掉tikv2135、tikv5138两台主机情况下，整个集群并不会受到影响，因为只有一个region副本分布在这两台机器之上，但这仅仅是当数据库的数据量较小的情况，当数据量增大PD调度将会对region的分布进行调度。对于挂掉一个副本的情况，在此不进行模拟。

我们采用同时宕掉Tikv1134和Tikv3136这两台机器，会出现region的两个副本丢失。需要先检查宕机前测试表的状况：

MySQL[sbtest2]> select count(*) from t_user;

+———-+

| count(*) |

+———-+

| 3000000 |

+———-+

1 row in set (6.98 sec)

同时宕掉Tikv3136和Tikv4137两台机器后，查询表的情况变为

MySQL[sbtest2]> select count(*) from t_user;

ERROR 9005 (HY000): Region is unavailable

出现了region不可用的报错。需要检查宕机的两台机器对应的store_id，并将四个参数设为0，关闭调度主要为将恢复过程中可能的异常情况降到最少，需在故障处理期间禁用相关的调度。

使用pd-ctl检查大于等于一半副本数在故障节点上的Region，并记录它们的ID。我们可以看到表的两个regionID均在列表中，另外的两个region由于只丢失一个副本，并未出现在列表中。在剩余正常的kv节点上执行停Tikv的操作。

在所有健康的节点上执行操作：tikv-ctl –db=/path/to/tikv-data/db unsafe-recover remove-fail-stores -s 4,5 –all-regions。当Region比较少，则可以在给定Region的剩余副本上，移除掉所有位于故障节点上的Peer。停止PD节点，重启启动PDtikv节点，检查没有处于leader状态的region并重新修改参数。查询数据是否正常，至此恢复操作结束。