数据库｜主中心意外故障？同城双中心教你紧急恢复

前言

什么是 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。

设置 DR Auto-Sync 架构

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

TiKV 中的设置：

[
  { "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"

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 是备中心副本的数量。

我们能够观察到，刚设置自适应同步模式后，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 的状态及分布，可能是设置出现问题，需要重新检查。

config show all
config placement-rules show

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

主中心故障，集群恢复

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

//Step1：查看主dc的store信息

select STORE_ID,STORE_STATE,ADDRESS from INFORMATION_SCHEMA.TIKV_STORE_STATUS;

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

二、主中心故障后的处理

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 cluster restart tidb-bbg -N 10.3.65.136:2379

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

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

config set replication-mode majority

unsafe remove-failed-stores 1,4,5

unsafe remove-failed-stores show

总结