TiDB：多数派节点故障恢复操作指南

TiDB 社区干货传送门

于 2024-05-29 00:00:00 发布

阅读量419

点赞数 3

文章标签： tidb

本文链接：https://blog.csdn.net/TiDBer/article/details/145068552

版权

作者：这里介绍不了我原文来源： https://tidb.net/blog/b72c3144

no-alt

（1）我们所使用的 TiDB 目前采用 3 副本的部署方式，其中一份数据同时存储在多个节点中。然而，如果一个 Region 的多数或全部副本在短时间内全部下线，该 Region 将无法进行读写操作，对业务造成严重影响。

（2）在实际生产过程中，我们也曾遇到同一台交换机发生灾难性故障，如机房断电等情况，其下的多个 TIKV 宕机，也会造成多副本或全部副本丢失，导致业务不可用的情况。

no-alt

（3）社区当前多数文章只针对某一个版本在该场景下进行了故障恢复。而在 V6.1.0 正式引入 Online Unsafe Recovery 功能，所以本文将整合 V6.1.0 版本及其之前和之后的两个版本在该场景下故障解决方案。

对于 PD 来说，是如何获取某个 Region 的状态？

对于每个 Raft Group 的 Leader 和 PD 之间都存在心跳包，用于汇报这个 Region 的状态。心跳包中主要包括：

除此之外，PD 还会收集每个 TiKV 节点（Store）发送的心跳包。通过这两种心跳包得到的信息，PD 会通过一些策略来制定具体的调度计划。

而调度的基本操作大致分为：

假设我们现在有若干个 Region 分布在 5 个 Store 上，并且每个 Region 有3个副本，我们进行实验，手动挂掉3个 Store 。若剩余副本数等于 2，PD 可以通过调度进行 Leader 的重新选举以及副本的补充。但是若只剩余 1 个副本，那么就需要人工介入进行恢复。

首先，使用 tiup-bench 工具来准备一些测试数据：

tiup bench tpcc prepare --warehouses 4 --db xxx -H xxxx -P 4000 -pxxx

集群 store 情况：

这里用 IP+store id 代替真实 IP 地址。

Region 分布情况：

表名	Region id	Region leader	Region分布	Region leader 所在地址
customer	34768	11	[11,10,2]	IP11
customer	34780	1	[11,1,3]	IP1
customer	34772	10	[10,2,1]	IP10
customer	34776	11	[11,2,1]	IP11
district	34756	10	[10,2,3]	IP10
district	34764	1	[11,1,10]	IP1
district	34752	10	[1,10,2]	IP10
district	34760	1	[1,10,2]	IP1
history	34792	10	[10,3,2]	IP10
history	34799	1	[1,2,3]	IP1
history	34784	1	[1,10,2]	IP1
history	34788	2	[11,2,1]	IP2
item	70	10	[11,10,2]	IP10
new_order	34813	1	[1,10,2]	IP1
new_order	34826	11	[11,3,1]	IP11
new_order	34804	10	[10,3,1]	IP10
new_order	34808	2	[2,3,1]	IP2
order_line	34863	10	[10,3,11]	IP10
order_line	34859	11	[11,10,3]	IP11
order_line	34851	10	[10,3,1]	IP10
order_line	34855	1	[11,1,10]	IP1
orders	34839	1	[11,1,10 ]	IP1
orders	34830