作为 NewSQL 数据库，TiDB 兼顾了传统关系型数据库的特性以及 NoSQL 数据库可扩展性，以及跨数据中心场景下的高可用。在官方文档中给出了多种不同的多数据中心部署方案以及这些部署方案背后的取舍所带来不同的优缺点。本文旨在给出一种降低可用性需求仅实现灾备的 TiDB 多数据中心部署方案，通过放松可用性要求使用单一集群两数据中心部署的方式实现数据灾备的目标。
官方跨数据中心部署方案
跨数据中心部署方案 | TiDB 官方用户文档
- 三数据中心
三数据中心和两地三中心方案能得到的保障是任意一个数据中心故障时，集群能自动恢复服务，不需要人工介入，并能保证数据一致性。日常调度策略向性能优化倾斜，发生故障时调度策略则优先考虑可用性。
- 两数据中心
在仅具备两数据中心的情况下，官方也给出了两数据中心 + binlog 同步的方案。类似于传统的 MySQL 复制方案，两个数据中心分别部署一套完整的 TiDB 集群。根据业务特点可以选择 master/slave 或 master/master 方案进行数据复制。由于 binlog 异步复制的原因，在数据中心间的延迟较高的情况下，从集群落后主集群的数据量可能存在较大波动。写入集群故障后对复制目标集群读取时无法确保读到新的数据，无法访问到的数据量受网络延迟等因素影响。
- 高收益高成本
三数据中心方案作为业务侵入小的解决方案，在全自动的提供全局可用性的前提下还可以在系统常态运行中提供不输单数据中心部署的性能表现。但这需要具备三数据中心和高质量的专线互联，产生额外的机房相关建设成本。
相比之下两数据中心方案对机房数量和专线的稳定性要求都给出了更低的要求，但这种部署方案下主集群故障需要人工干预，并且存在复制延迟产生的数据不可见风险。除此以外运维两套集群以及维持集群间 binlog 复制可靠性也产生了更多的管理成本。
单集群两数据中心灾备方案
考虑到现有的机房数量和专线条件限制，我们暂不具备三中心部署 TiDB 高可用集群的前提条件。再考虑目前我们所有在线业务只存在于单一数据中心的现状，多数据中心多活的架构在基础设施和业务架构迭代有阶段性成果前不具备可操作性。在这些前提条件下，我们希望能既利用当前的在线 & 离线双数据中心，又可以部署单一 TiDB 集群的方式充分利用离线数据中心提升数据灾难恢复的能力。
与官方推荐的两数据中心部署方案不同的是，主数据中心拥有所有 region 的 leader 副本且至少拥有这些 region 的 quorum 个副本。在这种部署方案下，与在线业务部署在同一个数据中心的 majority 副本可以确保所有 raft 操作流程获得同单数据中心部署时相似的性能表现。同时我们还可以确保有一定数量的副本会存储在第二数据中心，在我们的场景里离线数据中心的服务器则承载了这些灾备副本。
实施方案
通过配合使用 location-labels 和 label-property 两个 PD 调度策略，我们可以实现前述两数据中心的灾备部署。需要注意的目前的调度策略并不直接支持单一数据中心维持 quorum 副本的调度策略。首先我们需要使用 reject-leader 的 label-property 策略将所有 leader 从离线数据中心进行驱逐。此外我们还需要人为将在线数据中心拆成两个虚拟数据中心，并将在线数据中心的节点平均分配到这两个虚拟数据中心中。通过将 location-labels 设定为 idc,host 让 PD 将三个副本均匀分散在三个数据中心里，由于三个数据中心中两个虚拟数据中心对应的是同一个物理数据中心，可以确保所有 region 都有两个副本存储于在线数据中心。同理如果我们希望使用 5 副本，可以通过分别将在线和离线数据中心拆分为三个和两个逻辑数据中心的方式实现我们希望的 placement 策略。
虽然我们可以通过上述方案实现两数据中心的灾备部署方案，但方案的实施并不理想。首先我们需要人工的将在线数据中心的服务器均衡的拆分到多个虚拟数据中心中，而我们都知道人工操作是易错的应当尽量避免的。其次当我们对一个已有的 TiDB 集群应用上述方案时，PD 无法感知虚拟数据中心和物理数据中心的位置相关性，会生成大量的数据搬迁任务对系统产生无意义的压力。
幸运的是 TiDB 4.0 给 PD 增加了更加灵活的 Placement Rules 功能支持，我们可以通过 API 的方式对系统的副本放置策略灵活的定制。考虑到 TiDB 4.0 发布尚有时日，并且生产系统的迁移本身会更加保守。我们为当前线上使用的 TiDB 3.0.x 增加了 reject quorum 的 label-property，将上述的副本放置策略以新增的 quorum-scheduler 调度器固化到 PD 中。只需要简单启用 quorum-scheduler 再配合系统内置的 label-scheduler 即可原生实现单集群两数据中心的灾备部署策略。
TiDB 4.0 有着众多令人激动人心的特性，其中 Placement Rules 是我们非常关注的一个重点特性。在面向多云、多数据中心的发展方向指引下，我们希望未来在 Placement Rules 可编程能力的帮助下，能够将业务领域知识同 TiDB 集群部署策略紧密结合起来，实现更贴合我们业务模式的 TiDB 多数据中心方案。
