同城双中心 DR Auto-Sync 主中心意外故障恢复
一、前言
在国内推动本土化的背景下，国内企业对国产数据库的需求越来越高。最近，我一直在各个地方进行 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，写入如下代码：
注意项：
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 设置：
说明：
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. 检查设置
3. 查看同步状态
四、主中心故障，集群恢复
在 DR Auto-Sync 架构中的集群，如果主中心突然故障无法启动，该怎么办呢？以下是官方文档，因为操作有丢失数据的风险，没有给出详细的解决方案。
以下是根据 PoC 测试的经验，结合专栏的文章整理的集群恢复步骤：
1、主中心故障前的准备工作
1. 查看主 dc 的 store 信息
记录好主中心的 store_id 恢复数据时需要用到。
2. 转移集群信息文件并删除主中心相关节点
拷贝集群信息主要是保证在主中心访问不了的情况下，备中心还能够使用 tiup 对集群进行管理。如果 tiup 不在主中心可以忽略此步骤。删除主中心相关节点是因为备中心会以新集群启动，然后做有损恢复，主中心的 tikv 会作为不可能上线的情况处理。
ps：在 PoC 测试中，我发现不删除主中心相关节点也能正常恢复集群，但是对生产环境来说肯定还是有风险的。
2、主中心故障后的处理
1. 启动 PD 节点
如果备中心集群状态的 PD 是启动状态，可跳过对 PD 的操作。如果备中心集群状态的 PD 是 down，则需要登录到该 PD 节点机器上，增加启动参数：
使用 tiup restart 重启 pd 节点：
查看集群状态，如果 PD 启动后，则需要执行：
模拟主中心故障：
启动 PD 节点：
2. 切换 Placement Rules 规划
用初始值来代替 DR Auto-Sync 的 Placement Rules 规划：
3. 取消 DR Auto-sync
设置成以前的三副本：
4. 有损恢复
去掉主中心的 store，这里的 id 是之前用 sql 查出来的 store_id：
5. 查看 store 状态
看到如下字样，即表示恢复完成，集群可正常提供服务。
集群状态如下，备中心的节点均正常。（由于 PD 分布不太对，我把 137 上的 PD 当成主中心做的实践）
region 分布：
到此，集群恢复已经完成。
五、总结
开启 DR Auto-Sync 架构的时候，一定要仔细仔细再仔细，把各项配置核对准确再进行设置。我因为之前不熟悉，配置写错了，又没有报错，DR Auto-Sync 架构的 region 状态一直不是预期的。
DR Auto-Sync 架构对网络延迟和带宽的要求一定要满足，不然会有很多问题。比如：插入的数据会一直等待 learner 写入完成，才算插入完成，网络延迟越高，写入速度越慢。
在生产环境中，数据的备份、恢复备中心的准备工作都要做好，才能保证数据的安全。数据量越大，备中心的恢复耗时越长，需要做好时间上的安排。
作者介绍：caiyfc，来自神州数码钛合金战队，是一支致力于为企业提供分布式数据库 TiDB 整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景，全部拥有 TiDB 高级资格证书，并活跃于 TiDB 开源社区，是官方认证合作伙伴。目前已为 10+ 客户提供了专业的 TiDB 交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/cabd70de8e5ea249b756471d8】。文章转载请联系作者。
TiDB 社区官网:https://tidb.net/ 2021-12-15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论