一、前言

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

单区域双 AZ 集群架构图

该集群采用推荐的 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交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。

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