数据库｜同城双中心 DR Auto-Sync 主中心意外故障恢复

妖狐艹你老母 2023-10-14 16:33 44阅读 0赞

### **一、前言** ###

最近，我一直在各个地方进行 TiDB 的 Poc 测试。在这些测试中，客户特别关注同城双中心或者两地三中心的架构体系，经常会找我了解 TiDB 灾备架构的实现方案和底层逻辑。基于客户对 RPO =0 的要求，我一般会向他们介绍 DR Auto-Sync 架构，也就是官网中的自适应同步模式，这是唯一能保证 RPO =0 的灾备架构。

根据 PoC 测试的经验，结合专栏的文章，我总结了开启 DR Auto-Sync 和主中心故障恢复的流程及注意事项。

### **二、什么是 DR Auto-Sync** ###

TiDB 通常采用多 AZ 部署方案保证集群高可用和容灾能力。多 AZ 部署方案包括单区域多 AZ 部署模式、双区域多 AZ 部署模式等多种部署模式。单区域双 AZ 部署方案，即在同一区域部署两个 AZ，成本更低，同样能满足高可用和容灾要求。该部署方案采用自适应同步模式，即 Data Replication Auto Synchronous，简称 DR Auto-Sync。

单区域双 AZ 部署方案下，两个 AZ 通常位于同一个城市或两个相邻城市（例如北京和廊坊），相距 50 km 以内，AZ 间的**网络连接延迟小于 1.5 ms，带宽大于 10 Gbps。**

![43c25cc5a0cc071051c75a83db238069.png][]

*  该集群采用推荐的 6 副本模式，其中 AZ1 中放 3 个 Voter，AZ2 中放 2 个 Follower 副本和 1 个 Learner 副本。TiKV 按机房的实际情况打上合适的 Label。
 *  副本间通过 Raft 协议保证数据的一致性和高可用，对用户完全透明。

该部署方案定义了三种状态来控制和标示集群的同步状态，该状态约束了 TiKV 的同步方式。集群的复制模式可以自动在三种状态之间自适应切换。要了解切换过程，请参考状态转换。

*  **sync：**同步复制模式，此时从 AZ (DR) 至少有一个副本与主 AZ (PRIMARY) 进行同步，Raft 算法保证每条日志按 Label 同步复制到 DR。
 *  **async：**异步复制模式，此时不保证 DR 与 PRIMARY 完全同步，Raft 算法使用经典的 majority 方式复制日志。
 *  **sync-recover：**恢复同步，此时不保证 DR 与 PRIMARY 完全同步，Raft 逐步切换成 Label 复制，切换成功后汇报给 PD。

### **三、设置 DR Auto-Sync 架构** ###

本次准备的集群如下：

![480d61b36d01e02e8be4b162362a6c1e.png][]

存储拓扑如下：

![645a86b08f0844758dfc0294eb881a20.png][]

本次会设置 3+2+1 的架构，也就是6 副本（3 个 Voter 副本在主中心，2 个 Follower 副本和 1 个 Learner 副本在备中心）

#### **Step1：设置 Label** ####

在 PD 中的设置：

![efabf17a201a3efd649999aa59b30c02.png][]

这里的zone 也可以写成 az 或是其他，但是一定要和后续配置**保持一致。**

TiKV 中的设置：

![11d20549beb708d8a48310600b287e58.png][]

这里的 labels 要与 PD 的设置保持一致。

#### **Step2：设置 Placement Rules 规划** ####

新建一个文件 Untitled-1.json，写入如下代码：

[
    {
    "group_id": "pd",
    "group_index": 0,
    "group_override": false,
    "rules": [
    {
    "group_id": "pd",
    "id": "voters",
    "start_key": "",
    "end_key": "",
    "role": "voter",
    "count": 3,
    "label_constraints": [{"key": "zone", "op": "in", "values": ["west"]}],
    "location_labels": ["zone","rack","host"]},
    {
    "group_id": "pd",
    "id": "followers",
    "start_key": "",
    "end_key": "",
    "role": "follower",
    "count": 2,
    "label_constraints": [{"key": "zone", "op": "in", "values": ["east"]}],
    "location_labels": ["zone", "rack", "host"]},
    {
    "group_id": "pd",
    "id": "learners",
    "start_key": "",
    "end_key": "",
    "role": "learner",
    "count": 1,
    "label_constraints": [{"key": "zone", "op": "in", "values": ["east"]}],
    "location_labels": ["zone", "rack", "host"]
    }
    ]
    }
    ]

**注意项：**

*  **id不能重复，**建议写 voters，followers，learners 用于区分各副本用途
 *  role 写副本的角色
 *  location\_labels 需要与 PD 的 label 保持一致
 *  label\_constraints 可以填写不同的颗粒度，比如中心、机架、机器。但是key的值，必须在 PD 的 label 中存在，比如颗粒度是中心，key 就需要写成 zone，颗粒度是机器，key需要写成host
 *  备份原始 Placement Rules，便于回退：pd-ctl config placement-rules rule-bundle load --out="default.json"

#### **Step3：启用自适应同步模式** ####

使用 pd-ctl 设置：

tiup ctl:v7.1.0pd -u http://10.3.65.146:2379-i

# 设置 placement-rules 
    config placement-rules rule-bundle save --in="rule.json"
    
    config set replication-mode dr-auto-sync
    config set replication-mode dr-auto-sync label-key zone
    config set replication-mode dr-auto-sync primary west
    config set replication-mode dr-auto-sync dr east
    config set replication-mode dr-auto-sync primary-replicas 3
    config set replication-mode dr-auto-sync dr-replicas 2

**说明：**

*  replication-mode 为待启用的复制模式，以上示例中设置为 dr-auto-sync。默认使用 majority 算法。
 *  label-key 用于区分不同的中心，需要和 Placement Rules 相匹配。
 *  primary 是主中心 zone 的值，即 west。
 *  dr 是备中心 zone 的值，即 east。
 *  primary-replicas 是主中心副本的数量。
 *  dr-replicas 是备中心副本的数量。

![054bdb775be92f37cca77d31d7131ce9.png][]

**Step4：查看DR Auto-Sync架构状态**

**1. 设置自适应同步模式后region状态**

![071f7eb10ff8dee00251fe227c3463d4.png][]

我们能够观察到，刚设置自适应同步模式后，PD 会检测到大量 miss peer 和 pending peer，也就时说，设置完成后，集群的三副本会直接变为六副本，多出来的三个部分没有及时补全，才会出现丢失副本和补充副本的现象。所以我们需要等待一些时间，或者调整store limit 参数，加速补充副本，直到 learner peer 稳定。这个时候，DR Auto-Sync 架构状态才是正常的。

让我们看看稳定后的leader和region分布吧:

![5a74e23e65ed49bb0636dda11b9342a8.png][]

由于只设置了三个 voter，所以 leader 都集中在三个 voter 所在 TiKV 节点上，region 在所有节点上分布均衡。如果主中心停止两个 voter，还需要让集群正常提供服务，可以把两个 follower 副本改为 voter，一共五个 voter 就可以满足这类需求。

如果设置您设置好的 DR Auto-Sync 架构不满足以上 region 的状态及分布，可能是设置出现问题，需要重新检查。

**2. 检查设置**

config showall
    config placement-rulesshow

![83c0e718747a30adeac6a9b920938c92.png][]

![6bfd56d0c00545398498c53766e0043a.png][]

**3. 查看同步状态**

curl http://10.3.65.146:2379/pd/api/v1/replication_mode/status

{
    "mode": "dr-auto-sync",
    "dr-auto-sync": {
    "label_key": "zone",
    "state": "sync",
    "state_id": 64861,
    "acid_consistent": true
    }
    }

### **四、主中心故障，集群恢复** ###

在 DR Auto-Sync 架构中的集群，如果主中心突然故障无法启动，该怎么办呢？以下是官方文档，因为操作有丢失数据的风险，没有给出详细的解决方案。

![dc6103388a69bdc62f1324c3e679b0e0.png][]

以下是根据 PoC 测试的经验，结合专栏的文章整理的集群恢复步骤：

### **（一）主中心故障前的准备工作** ###

#### **Step1：查看主dc的store信息** ####

selectSTORE_ID,STORE_STATE,ADDRESS fromINFORMATION_SCHEMA.TIKV_STORE_STATUS;

![7e48196dc4ab15809be470d0f9d89c43.png][]

记录好主中心的 store\_id 恢复数据时需要用到。

#### **Step2：转移集群信息文件并删除主中心相关节点** ####

scp -r .tiup/storage/cluster/clusters/tidb-bbg 10.3.65.146:/home/tidb/.tiup/storage/cluster/clusters/
    
    vi .tiup/storage/cluster/clusters/tidb-bbg/meta.yaml

拷贝集群信息主要是保证在主中心访问不了的情况下，备中心还能够使用 tiup 对集群进行管理。如果 tiup 不在主中心可以忽略此步骤。删除主中心相关节点是因为备中心会以新集群启动，然后做有损恢复，主中心的 tikv 会作为不可能上线的情况处理。

ps：在 PoC 测试中，我发现不删除主中心相关节点也能正常恢复集群，但是对生产环境来说肯定还是有风险的。

### **（二）主中心故障后的处理** ###

#### **Step1：启动PD节点** ####

如果备中心集群状态的 PD 是启动状态，可跳过对 PD 的操作。如果备中心集群状态的 PD 是 down，则需要登录到该 PD 节点机器上，增加启动参数：

scp -r .tiup/storage/cluster/clusters/tidb-bbg 10.3.65.146:/home/tidb/.tiup/storage/cluster/clusters/
    vi .tiup/storage/cluster/clusters/tidb-bbg/meta.yaml

使用 tiup restart 重启 pd 节点：

tiupclusterrestarttidb-bbg-N10.3.65.136:2379

查看集群状态，如果 PD 启动后，则需要执行：

tiup pd-recover--from-old-member --endpoints=http://10.3.65.136:2379

模拟主中心故障：

![35e7827ffaaa43696ac1c8cc1da269d3.png][]

启动 PD 节点：

![format_png][]

![0daf9e51c38978f21565b733f66748b2.png][]

#### **Step2：切换 Placement Rules 规划** ####

用初始值来代替 DR Auto-Sync 的 Placement Rules 规划：

config placement-rules rule-bundle save --in="default.json"

#### **Step3：取消DR Auto-sync** ####

设置成以前的三副本：

config setreplication-modemajority

#### **Step4：有损恢复** ####

去掉主中心的store，这里的 id 是之前用 sql 查出来的 store\_id：

unsaferemove-failed-stores 1,4,5

#### **Step5：查看 store 状态** ####

unsaferemove-failed-stores show

看到如下字样，即表示恢复完成，集群可正常提供服务。

![6644d7d5608169d2f61d3ea9d0293bf7.png][]

集群状态如下，备中心的节点均正常。（由于 PD 分布不太对，我把137上的 PD 当成主中心做的实践）

![0ab7be7b6497e5dfe0e7d6de2c1d525c.png][]

region分布：

![f5d518c097879131197c756ccb04048b.png][]

到此，集群恢复已经完成。

### **五、总结** ###

1.  在开启 DR Auto-Sync 架构之前，务必要仔细核对各项配置的准确性。由于我之前不熟悉，配置写错了，而且没有报错信息，导致 DR Auto-Sync 架构的 region 状态一直与预期不符。
2.  DR Auto-Sync 架构对网络延迟和带宽有一定要求，必须满足才能避免出现问题。例如，插入的数据会一直等待 learner 写入完成才算插入完成，而网络延迟越高，写入速度就越慢。
3.  在生产环境中，必须做好数据备份和备中心的准备工作，以确保数据的安全性。数据量越大，备中心的恢复耗时就会越长，需要合理安排时间来完成这些工作。

作者：**蔡一凡**|后端开发工程师

***公众号搜索神州数码云基地，后台回复数据库，加入数据库技术交流群。***

[43c25cc5a0cc071051c75a83db238069.png]: https://img-blog.csdnimg.cn/img_convert/43c25cc5a0cc071051c75a83db238069.png
[480d61b36d01e02e8be4b162362a6c1e.png]: https://img-blog.csdnimg.cn/img_convert/480d61b36d01e02e8be4b162362a6c1e.png
[645a86b08f0844758dfc0294eb881a20.png]: https://img-blog.csdnimg.cn/img_convert/645a86b08f0844758dfc0294eb881a20.png
[efabf17a201a3efd649999aa59b30c02.png]: https://img-blog.csdnimg.cn/img_convert/efabf17a201a3efd649999aa59b30c02.png
[11d20549beb708d8a48310600b287e58.png]: https://img-blog.csdnimg.cn/img_convert/11d20549beb708d8a48310600b287e58.png
[054bdb775be92f37cca77d31d7131ce9.png]: https://img-blog.csdnimg.cn/img_convert/054bdb775be92f37cca77d31d7131ce9.png
[071f7eb10ff8dee00251fe227c3463d4.png]: https://img-blog.csdnimg.cn/img_convert/071f7eb10ff8dee00251fe227c3463d4.png
[5a74e23e65ed49bb0636dda11b9342a8.png]: https://img-blog.csdnimg.cn/img_convert/5a74e23e65ed49bb0636dda11b9342a8.png
[83c0e718747a30adeac6a9b920938c92.png]: https://img-blog.csdnimg.cn/img_convert/83c0e718747a30adeac6a9b920938c92.png
[6bfd56d0c00545398498c53766e0043a.png]: https://img-blog.csdnimg.cn/img_convert/6bfd56d0c00545398498c53766e0043a.png
[dc6103388a69bdc62f1324c3e679b0e0.png]: https://img-blog.csdnimg.cn/img_convert/dc6103388a69bdc62f1324c3e679b0e0.png
[7e48196dc4ab15809be470d0f9d89c43.png]: https://img-blog.csdnimg.cn/img_convert/7e48196dc4ab15809be470d0f9d89c43.png
[35e7827ffaaa43696ac1c8cc1da269d3.png]: https://img-blog.csdnimg.cn/img_convert/35e7827ffaaa43696ac1c8cc1da269d3.png
[format_png]: https://img-blog.csdnimg.cn/img_convert/eea03972673d33cb9beccb8e8e9113ca.webp?x-oss-process=image/format,png
[0daf9e51c38978f21565b733f66748b2.png]: https://img-blog.csdnimg.cn/img_convert/0daf9e51c38978f21565b733f66748b2.png
[6644d7d5608169d2f61d3ea9d0293bf7.png]: https://img-blog.csdnimg.cn/img_convert/6644d7d5608169d2f61d3ea9d0293bf7.png
[0ab7be7b6497e5dfe0e7d6de2c1d525c.png]: https://img-blog.csdnimg.cn/img_convert/0ab7be7b6497e5dfe0e7d6de2c1d525c.png
[f5d518c097879131197c756ccb04048b.png]: https://img-blog.csdnimg.cn/img_convert/f5d518c097879131197c756ccb04048b.png