## 概览 > [!NOTE] > 本实验仅支持 Chrome 浏览器。 本动手实验基于提供的[官方文档](https://docs.pingcap.com/zh/tidb/v8.1/two-data-centers-in-one-city-deployment/)，将带您学习如何部署跨两个数据中心的分布式 TiDB 系统的实用技能。 在金融行业中，双数据中心架构是常见的部署模式，尤其在核心业务系统中，银行和金融机构对数据高可用性和灾备能力有极高要求。TiDB 的 DR Auto-Sync 方案正是为这种环境设计的，它能够在双数据中心基础设施下提供强大的数据保护能力，确保 RPO（恢复点目标）为 0 和分钟级的 RTO（恢复时间目标）。具体而言，该方案具备以下特点： + 支持 RPO = 0：确保任何数据中心故障情况下不会丢失数据。 + 支持分钟级 RTO：故障发生后能够在几分钟内恢复服务。 + 支持双活服务：允许两个数据中心同时提供高可用数据服务。 本实验模拟了在双数据中心场景下部署 DR Auto-Sync 的过程，展示如何在任一数据中心不可用或网络断开时，实现数据一致性和高可用性。 ### DR Auto-Sync 方案介绍 默认部署的挑战 + 默认情况下，所有数据库副本（3 个副本）形成一个 Raft 组，其中任意两个副本即可确保数据库的可用性和数据持久性。对于每次数据写入，只要在 Raft 组内的任意两个 TiKV 中提交成功，客户端就会收到成功响应。然而，如果 DC1 持有最新的两个数据副本并发生完全宕机，这两个副本就会丢失，而 Raft 组无法保证最新数据已复制到 DC2。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-1-en.png) DR Auto-Sync 方案 + 该方案在 Raft 算法中引入了 commit group（提交组）的概念。写入数据提交时，不仅要满足多数节点持久化的原则，还必须在至少两个 commit group 中提交完成。通过设置两个数据中心分别对应一个 commit group，保证了两个数据中心都持有最新的数据副本，确保这任一数据中心故障情况下的数据安全。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-2-en.png) 此外，该方案在 DC2 中包含一个额外的 `learner` 节点，它不参与投票，仅在 DC2 是唯一存活的数据中心时用于恢复 TiDB 集群。 DR Auto-Sync 的高可用场景 + DR Auto-Sync 方案使用三种不同的状态来标识 TiKV 数据同步模式。集群的复制模式可以在这三种状态之间自适应切换。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-3-en.png) + 同步模式：TiDB 默认在同步复制模式下运行。在此模式下，灾备数据中心中至少有一个副本与主数据中心同步。Raft 算法确保写入的最新数据都在到灾备数据中心得到持久化。在这种状态下，任一数据中心的整体故障都能确保 TiDB 集群达到 RPO=0。 + 异步模式：当某个数据中心发生整体故障时，TiDB 切换到异步复制模式。在此模式下，这两个数据中心的数据未完全同步。Raft 算法退化为仅遵循多数派协议，在存活的数据中心内完成复制数据。由于已经发生故障，如果发生第二次故障，TiDB 集群无法保证 RPO=0。只有在初始故障解决后，集群才能重新获得 RPO=0 的高可用能力。 + 同步恢复模式：当故障的数据中心恢复后，两个数据中心之间开启数据同步。此时，TiDB 切换到同步恢复模式，此模式意味着这两个数据中心同步在进行中。数据同步完成后，TiDB 重新切换回同步模式。然后，TiDB 集群重新获得 RPO=0 高可用能力。 ### 实验任务 + 模块 1：搭建 TiDB 集群并配置 DR Auto-Sync 部署，验证高可用模式的正确设置。 + 模块 2：模拟灾备数据中心发生故障或网络隔离，观察集群的自动切换和恢复机制。 + 模块 3：模拟主数据中心发生故障，验证集群的故障切换行为及快速恢复能力。 > [!TIP] > 点击 **开始** 启动实验环境。 > 环境准备就绪后，分配给您的动手实践会话的资源将填充实际值，您才可以按照实验指南逐步完成练习。