一、前言

在国内推动本土化的背景下，国内企业对国产数据库的需求越来越高。最近，我一直在各个地方进行 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。

该集群采用推荐的 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 架构

本次准备的集群如下：

存储拓扑如下：

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

1、设置 Label

在 PD 中的设置：

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

TiKV 中的设置：

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

2、设置 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"

3、启用自适应同步模式

使用 pd-ctl 设置：

tiup ctl:v7.1.0 pd -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 是备中心副本的数量。

4、查看 DR Auto-Sync 架构状态

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

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

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

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

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

2.检查设置

config show all config placement-rules show

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

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

1、主中心故障前的准备工作

1.查看主dc的store信息

select STORE_ID,STORE_STATE,ADDRESS from INFORMATION_SCHEMA.TIKV_STORE_STATUS;

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

2.转移集群信息文件并删除主中心相关节点

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 测试中，我发现不删除主中心相关节点也能正常恢复集群，但是对生产环境来说肯定还是有风险的。

2、主中心故障后的处理

1.启动 PD 节点

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

sed -i /pd-server/ s#pd-server#pd-server --force-new-cluster# /home/tidb/tidb-deploy/pd-2379/scripts/run_pd.sh

使用 tiup restart 重启 pd 节点：

tiup cluster restart tidb-bbg -N 10.3.65.136:2379

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

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

模拟主中心故障：

启动 PD 节点：

2.切换 Placement Rules 规划

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

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

3.取消DR Auto-sync

设置成以前的三副本：

config set replication-mode majority

4.有损恢复

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

unsafe remove-failed-stores 1,4,5

5.查看store 状态

unsafe remove-failed-stores show

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

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

region分布：

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

五、总结

开启 DR Auto-Sync 架构的时候，一定要仔细仔细再仔细，把各项配置核对准确再进行设置。我因为之前不熟悉，配置写错了，又没有报错，DR Auto-Sync 架构的 region 状态一直不是预期的。

DR Auto-Sync 架构对网络延迟和带宽的要求一定要满足，不然会有很多问题。比如：插入的数据会一直等待 learner 写入完成，才算插入完成，网络延迟越高，写入速度越慢。

在生产环境中，数据的备份、恢复备中心的准备工作都要做好，才能保证数据的安全。数据量越大，备中心的恢复耗时越长，需要做好时间上的安排。

作者介绍：caiyfc，来自神州数码钛合金战队，是一支致力于为企业提供分布式数据库TiDB整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景，全部拥有TiDB高级资格证书，并活跃于TiDB开源社区，是官方认证合作伙伴。目前已为10+客户提供了专业的TiDB交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。