title: 同城两中心自适应同步模式部署 summary: 了解同城使用两中心自适应同步模式部署方式。

同城两中心自适应同步模式部署

本文介绍同城两中心的部署模式，相关架构、示例配置、副本方法、启用该模式的方法。

简介

TiDB 在 on-premises 部署的场景下，通常采用多中心部署方案，以保证高可用和容灾能力。多中心部署方案包括两地三中心部署模式、同城三中心部署模式等多种部署模式。本文介绍同城两中心部署方案，即在一座城市部署两个数据中心，成本更低，同样能满足高可用和容灾要求。该部署方案采用自适应同步模式，即 Data Replication Auto Synchronous，简称 DR Auto-Sync。

同城两中心部署方案下，两个数据中心距离在 50 km 以内，通常位于同一个城市或两个相邻城市（例如北京和廊坊），数据中心间的网络连接延迟小于 1.5 ms，带宽大于 10 Gbps。

部署架构

本文以某城市为例，城里有两个数据中心 IDC1 和 IDC2，分为位于城东和城西。

下图为集群部署架构图，具体如下：

  • 集群采用同城两种中心部署方案，主数据中心 IDC1 在城东，从数据中心 IDC2 在城西。
  • 集群采用推荐的 4 副本模式，其中 IDC1 中放 2 个 Voter 副本，IDC2 中放 1 个 Voter 副本 + 1 个 Learner 副本；TiKV 按机房的实际情况打上合适的 Label。
  • 副本间通过 Raft 协议保证数据的一致性和高可用，对用户完全透明。

同城两中心集群架构图

该部署方案定义了三种状态来控制和标示集群的同步状态，该状态约束了 TiKV 的同步方式。集群的复制模式可以自动在三种状态之间自适应切换。要了解切换过程，请参考状态转换。

  • sync：同步复制模式，此时从数据中心 (DR) 至少有一个副本与主数据中心 (PRIMARY) 进行同步，Raft 算法保证每条日志 (log) 按 Label 同步复制到 DR。
  • async：异步复制模式，此时不保证 DR 与 PRIMARY 完全同步，Raft 算法使用经典的 majority 方式复制日志。
  • sync-recover：恢复同步，此时不保证 DR 与 PRIMARY 完全同步，Raft 逐步切换成 Label 复制，切换成功后汇报给 PD。

配置

示例

以下 tiup topology.yaml 示例拓扑文件为同城两中心典型的拓扑配置：

  1. # # Global variables are applied to all deployments and used as the default value of
  2. # # the deployments if a specific deployment value is missing.
  3. global:
  4.   user: "tidb"
  5.   ssh_port: 22
  6.   deploy_dir: "/data/tidb_cluster/tidb-deploy"
  7.   data_dir: "/data/tidb_cluster/tidb-data"
  8. server_configs:
  9.   pd:
  10.     replication.location-labels:  ["zone","rack","host"]
  11. pd_servers:
  12.   - host: 10.63.10.10
  13.     name: "pd-10"
  14.   - host: 10.63.10.11
  15.     name: "pd-11"
  16.   - host: 10.63.10.12
  17.     name: "pd-12"
  18. tidb_servers:
  19.   - host: 10.63.10.10
  20.   - host: 10.63.10.11
  21.   - host: 10.63.10.12
  22. tikv_servers:
  23.   - host: 10.63.10.30
  24.     config:
  25.       server.labels: { zone: "east", rack: "east-1", host: "30" }
  26.   - host: 10.63.10.31
  27.     config:
  28.       server.labels: { zone: "east", rack: "east-2", host: "31" }
  29.   - host: 10.63.10.32
  30.     config:
  31.       server.labels: { zone: "west", rack: "west-1", host: "32" }
  32.   - host: 10.63.10.33
  33.     config:
  34.       server.labels: { zone: "west", rack: "west-2", host: "33" }
  35. monitoring_servers:
  36.   - host: 10.63.10.60
  37. grafana_servers:
  38.   - host: 10.63.10.60
  39. alertmanager_servers:
  40.   - host: 10.63.10.60

Placement Rules 规划

为了按照规划的集群拓扑进行部署，你需要使用 Placement Rules 来规划集群副本的放置位置。以 4 副本和 2 Voter 副本在主数据中心，1 Voter 和 1 Learner 在从数据中心的部署方式为例，可使用 Placement Rules 进行如下副本配置：

  1. cat rule.json
  2. [
  3.   {
  4.     "group_id": "pd",
  5.     "id": "zone-east",
  6.     "start_key": "",
  7.     "end_key": "",
  8.     "role": "voter",
  9.     "count": 2,
  10.     "label_constraints": [
  11.       {
  12.         "key": "zone",
  13.         "op": "in",
  14.         "values": [
  15.           "east"
  16.         ]
  17.       }
  18.     ],
  19.     "location_labels": [
  20.       "zone",
  21.       "rack",
  22.       "host",
  23.     ]
  24.   },
  25.   {
  26.     "group_id": "pd",
  27.     "id": "zone-west",
  28.     "start_key": "",
  29.     "end_key": "",
  30.     "role": "voter",
  31.     "count": 1,
  32.     "label_constraints": [
  33.       {
  34.         "key": "zone",
  35.         "op": "in",
  36.         "values": [
  37.           "west"
  38.         ]
  39.       }
  40.     ],
  41.     "location_labels": [
  42.       "zone",
  43.       "rack",
  44.       "host"
  45.     ]
  46.   },
  47.   {
  48.     "group_id": "pd",
  49.     "id": "zone-west",
  50.     "start_key": "",
  51.     "end_key": "",
  52.     "role": "learner",
  53.     "count": 1,
  54.     "label_constraints": [
  55.       {
  56.         "key": "zone",
  57.         "op": "in",
  58.         "values": [
  59.           "west"
  60.         ]
  61.       }
  62.     ],
  63.     "location_labels": [
  64.       "zone",
  65.       "rack",
  66.       "host"
  67.     ]
  68.   }
  69. ]

启用自适应同步模式

副本的复制模式由 PD 节点控制。如果要使用 DR Auto-sync 自适应同步模式，需要在部署集群前先配置好 PD 的配置文件，如下所示：

  1. [replication-mode]
  2. replication-mode = "dr-auto-sync"
  3. [replication-mode.dr-auto-sync]
  4. label-key = "zone"
  5. primary = "east"
  6. dr = "west"
  7. primary-replicas = 2
  8. dr-replicas = 1
  9. wait-store-timeout = "1m"
  10. wait-sync-timeout = "1m"

在以上配置文件中：

  • replication-mode 为待启用的复制模式，以上示例中设置为 dr-auto-sync。默认使用 majority 算法。
  • label-key 用于区分不同的数据中心，需要和 Placement Rules 相匹配。其中主数据中心为 “east”，从数据中心为 “west”。
  • primary-replicas 是在主数据中心 Voter 副本的数量。
  • dr-replicas 是在从数据中心 Voter 副本的数量。
  • wait-store-timeout 是当出现网络隔离或者故障时，切换到异步复制模式的等待时间。如果超过这个时间还没恢复，则自动切换到异步复制模式。默认时间为 60 秒。

如果需要检查当前集群的复制状态，可以通过以下 API 获取：

  1. curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status
  1. {
  2.   "mode": "dr-auto-sync",
  3.   "dr-auto-sync": {
  4.     "label-key": "zone",
  5.     "state": "sync"
  6.   }
  7. }

状态转换

简单来讲，集群的复制模式可以自动在三种状态之间自适应的切换：

  • 当集群一切正常时，会进入同步复制模式来最大化地保障灾备机房的数据完整性。
  • 当机房网络断连或灾备机房发生整体故障时，在经过一段提前设置好的保护窗口之后，集群会进入异步复制状态，来保障业务的可用性。
  • 当机房网络重连或灾备机房整体恢复之后，灾备机房的 TiKV 节点会重新加入到集群，逐步同步数据并最终转为同步复制模式。

状态转换的细节过程如下：

  1. 初始化：集群在初次启动时处于 sync（同步复制）模式，PD 会下发信息给 TiKV，所有 TiKV 节点会严格按照 sync 模式的要求进行工作。

  2. 同步切异步：PD 通过定时检查 TiKV 的心跳信息来判断 TiKV 是否宕机或断连。如果宕机数超过 PRIMARY/DR 各自副本的数量 primary-replicas 和 dr-replicas，意味着无法完成同步复制，需要切换状态。当宕机时间超过了 wait-store-timeout 设定的时间，PD 将集群状态切换成 async（异步复制）模式。然后 PD 再将 async 状态下发到所有 TiKV 节点，TiKV 的复制模式由双中心同步方式转为原生的 Raft 大多数落实方式 (majority)。

  3. 异步切同步：PD 通过定时检查 TiKV 的心跳信息来判断 TiKV 是否恢复连接，如果宕机数小于 PRIMARY/DR 各自副本的数量，意味着可以切回同步了。PD 会将集群复制状态先切换至 sync-recover，再将该状态下发给所有 TiKV 节点。TiKV 的所有 Region 逐步切换成双机房同步复制模式，切换成功后通过心跳将状态同步信息给 PD。PD 记录 TiKV 上 Region 的状态并统计恢复进度。当 TiKV 的所有 Region 都完成了同步复制模式的切换，PD 将集群复制状态切换为 sync。

灾难恢复

本节介绍同城两中心部署提供的容灾恢复方案。

当处于同步复制状态的集群发生了灾难，可进行 RPO = 0 的数据恢复：

  • 如果主数据中心发生故障，丢失了大多数 Voter 副本，但是从数据中心有完整的数据，可在从数据中心恢复数据。此时需要人工介入，通过专业工具恢复（恢复方式请联系 TiDB 团队）。

  • 如果从数据中心发生故障，丢失了少数 Voter 副本，能自动切换成 async 异步复制模式。

当不处于同步复制状态的集群发生了灾难，不能保证满足 RPO = 0 进行数据恢复：

  • 如果丢失了大多数 Voter 副本，需要人工介入，通过专业工具恢复（恢复方式请联系 TiDB 团队）。