diff --git a/TOC.md b/TOC.md index a2b5adc2eba3..f688ddd73503 100644 --- a/TOC.md +++ b/TOC.md @@ -156,6 +156,11 @@ - [使用 Dumpling 和 TiDB Lightning 备份与恢复](/backup-and-restore-using-dumpling-lightning.md) - [备份与恢复 RawKV](/br/rawkv-backup-and-restore.md) - [增量备份与恢复](/br/br-incremental-guide.md) + - 集群容灾 + - [容灾方案介绍](/dr-solution-introduction.md) + - [基于主备集群的容灾](/dr-secondary-cluster.md) + - [基于多副本的单集群容灾](/dr-multi-replica.md) + - [基于备份与恢复的容灾](/dr-backup-restore.md) - [使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md) - [修改时区](/configure-time-zone.md) - [日常巡检](/daily-check.md) diff --git a/dr-backup-restore.md b/dr-backup-restore.md new file mode 100644 index 000000000000..76fccd165641 --- /dev/null +++ b/dr-backup-restore.md @@ -0,0 +1,29 @@ +--- +title: 基于备份与恢复的容灾方案 +summary: 了解如何基于 TiDB 的备份与恢复功能实现容灾。 +--- + +# 基于备份与恢复的容灾方案 + +TiDB 集群自身的多副本特性可以让其容忍单个机房或地理区域的故障，并继续向外提供服务。在更大范围的自然灾害、软件漏洞、硬件故障、病毒攻击或常见的人为误操作的情况下，TiDB 的备份与恢复功能可以将数据备份到独立的灾备存储设备中，以保护用户数据不受损坏。与其他方案相比，备份与恢复功能具有灵活性、可靠性、可恢复性和成本效益等优势： + +- 灵活性：可以在不同的时间点进行备份，并且可以根据需要调整备份频率。这使得备份与恢复功能更加灵活，能够更好地适应不同的业务场景。 +- 可靠性：备份与恢复功能通常会将备份数据保存在独立的存储设备上，使得数据安全得到进一步升级。 +- 可恢复性：任何意外情况导致的原始数据丢失或损坏，都可以通过恢复备份数据的方式来恢复。这使得备份恢复功能具有很高的可恢复性，能够保证数据库的正常使用。 +- 成本效益：备份恢复功能通常具有较低的成本，可以在不增加太多费用的情况下实现对数据库的安全保护。 + +总的来说，备份恢复功能是数据安全的最后一道防线，可以在不增加太多成本的情况下，提高数据库的安全性和可靠性。它能够在各种意外情况发生时保护数据，使你能够安心地使用数据库，而不必担心数据丢失或损坏的风险。 + +## 进行备份恢复 + +![BR log backup and PITR architecture](/media/dr/dr-backup-and-restore.png) + +按照上述架构，你可以将数据备份到其他区域的灾备存储设备中，并在需要时将数据恢复回来。这样，系统就能够容忍单个区域的故障，并且 Recovery Point Objective (RPO) 可以达到 5 分钟，Recovery Time Objective (RTO) 通常在几十分钟到数小时之间。但是，如果数据库尺寸较大，RTO 时间可能会更长。 + +此外，TiDB 还提供了基于块存储快照技术的备份和恢复特性，可以将集群的恢复时间缩短到小时级别甚至 1 小时以内。TiDB 也在不断完善和优化基于存储快照技术的备份和恢复能力，以提供更好的服务。 + +TiDB 提供了丰富的文档，帮助你了解如何在容灾场景下使用备份和恢复功能。其中， + +- [TiDB 备份和恢复功能使用概述](/br/br-use-overview.md)提供了备份与恢复的使用指引，包含备份策略及备份数据存放组织等。 +- [TiDB 备份恢复常见问题](/faq/backup-and-restore-faq.md)列出了使用备份与恢复功能时可能遇到的问题，以及解决方案。 +- [TiDB 备份与恢复功能架构](/br/backup-and-restore-design.md)描述了 TiDB 备份与恢复功能的设计架构，包括备份和恢复的流程，以及备份文件设计。 diff --git a/dr-multi-replica.md b/dr-multi-replica.md new file mode 100644 index 000000000000..84ded6306ab7 --- /dev/null +++ b/dr-multi-replica.md @@ -0,0 +1,209 @@ +--- +title: 基于多副本的单集群容灾方案 +summary: 了解 TiDB 提供的基于多副本的单集群容灾方案。 +--- + +# 基于多副本的单集群容灾方案 + +本文介绍了基于多副本的单集群容灾方案，文档内容组织如下： + +- 方案简介 +- 搭建集群 +- 配置副本 +- 监控集群 +- 容灾切换 + +## 简介 + +对于重要的生产系统，很多用户需要能够实现区域级别的容灾，并且做到 RPO = 0 和分钟级别的 RTO。TiDB 作为基于 Raft 协议的分布式数据库，其自带的多副本特性可以用于支持区域级别的容灾目标，并同时确保数据的一致性和高可用性。而同区域可用区 (Available Zone, AZ) 之间的网络延迟相对较小，可以把业务流量同时派发到同区域两个 AZ，并通过控制 Region Leader 和 PD Leader 分布实现同区域 AZ 共同负载业务流量。 + +## 搭建集群和配置副本 + +在这一部分当中，会以一个 5 副本的集群为例，演示如何使用 TiUP 创建一个跨 3 个区域的集群，以及如何控制数据和 PD 的分布位置，从而达到容灾的目的。 + +在下面的示例中，TiDB 集群的区域 1 作为 primary region，区域 2 作为 secondary region，而区域 3 则作为投票使用的第三个区域，一共包含 5 个副本。同理，PD 集群也包含了 5 个副本，其功能和 TiDB 集群的功能基本一致。 + +1. 创建类似于以下的集群拓扑文件： + + ```toml + global: + user: "root" + ssh_port: 22 + deploy_dir: "/data/tidb_cluster/tidb-deploy" + data_dir: "/data/tidb_cluster/tidb-data" + + server_configs: + tikv: + server.grpc-compression-type: gzip + pd: + replication.location-labels: ["Region","AZ"] # PD 会根据 TiKV 节点的 Region 和 AZ 配置来进行副本的调度。 + + pd_servers: + - host: tidb-dr-test1 + name: "pd-1" + - host: tidb-dr-test2 + name: "pd-2" + - host: tidb-dr-test3 + name: "pd-3" + - host: tidb-dr-test4 + name: "pd-4" + - host: tidb-dr-test5 + name: "pd-5" + + tidb_servers: + - host: tidb-dr-test1 + - host: tidb-dr-test3 + + + tikv_servers: # 在 TiKV 节点中通过 labels 选项来对每个 TiKV 节点所在的 Region 和 AZ 进行标记 + - host: tidb-dr-test1 + config: + server.labels: { Region: "Region1", AZ: "AZ1" } + - host: tidb-dr-test2 + config: + server.labels: { Region: "Region1", AZ: "AZ2" } + - host: tidb-dr-test3 + config: + server.labels: { Region: "Region2", AZ: "AZ3" } + - host: tidb-dr-test4 + config: + server.labels: { Region: "Region2", AZ: "AZ4" } + - host: tidb-dr-test5 + config: + server.labels: { Region: "Region3", AZ: "AZ5" } + + raftstore.raft-min-election-timeout-ticks: 1000 + raftstore.raft-max-election-timeout-ticks: 1200 + + monitoring_servers: + - host: tidb-dr-test2 + + grafana_servers: + - host: tidb-dr-test2 + + alertmanager_servers: + - host: tidb-dr-test2 + ``` + + 在上面的配置中，使用了以下一系列配置来针对跨区域容灾场景进行优化： + + - 使用 `server.grpc-compression-type`：gzip 启用 TiKV 之间的消息压缩，从而降低网络流量。 + - 使用 `raftstore.raft-min-election-timeout-ticks` 和 `raftstore.raft-max-election-timeout-ticks` 延长区域 3 参加选举的时间，从而避免该区域中的副本被选举为主节点。 + +2. 使用上面的配置文件创建集群： + + ```shell + tiup cluster deploy drtest v6.4.0 ./topo.yaml + tiup cluster start drtest --init + tiup cluster display drtest + ``` + + 对集群的副本数和 Leader 限制进行配置： + + ```shell + tiup ctl:v6.4.0 pd config set max-replicas 5 + tiup ctl:v6.4.0 pd config set label-property reject-leader Region Region3 + + # 下面的步骤用于向集群中添加一些测试数据，可选 + tiup bench tpcc prepare -H 127.0.0.1 -P 4000 -D tpcc --warehouses 1 + ``` + + 指定 PD leader 的优先级: + + ```shell + tiup ctl:v6.4.0 pd member leader_priority pd-1 4 + tiup ctl:v6.4.0 pd member leader_priority pd-2 3 + tiup ctl:v6.4.0 pd member leader_priority pd-3 2 + tiup ctl:v6.4.0 pd member leader_priority pd-4 1 + tiup ctl:v6.4.0 pd member leader_priority pd-5 0 + ``` + + > **说明：** + > + > 优先级数值越大的节点成为 leader 的可能性越高。 + +3. 创建 placement rule，并将测试表的主副本固定在区域 1： + + ```sql + -- 创建两个 placement rules，第一个是区域 1 作为主区域，在系统正常时使用，第二个是区域 2 作为备区域。 + -- 作为主区域，当区域 1 出现问题时，区域 2 会作为主区域。 + MySQL [(none)]> CREATE PLACEMENT POLICY primary_rule_for_region1 PRIMARY_REGION="Region1" REGIONS="Region1, Region2,Region3"; + MySQL [(none)]> CREATE PLACEMENT POLICY secondary_rule_for_region2 PRIMARY_REGION="Region2" REGIONS="Region1,Region2,Region3"; + + -- 将刚刚创建的规则 primary_rule_for_region1 应用到对应的用户表上。 + ALTER TABLE tpcc.warehouse PLACEMENT POLICY=primary_rule_for_region1; + ALTER TABLE tpcc.district PLACEMENT POLICY=primary_rule_for_region1; + + -- 说明：请根据需要修改上面的数据库名称、表名和 placement rule 的名称。 + + -- 使用类似下面的查询，用户可以查看每个区域包含的 leader 数量，以确认 leader 迁移是否完成。 + SELECT STORE_ID, address, leader_count, label FROM TIKV_STORE_STATUS ORDER BY store_id; + ``` + + 下面的语句可以产生一个 SQL 脚本，把所有非系统 schema 中的表的 leader 都设置到特定的区域上： + + ```sql + SET @region_name=primary_rule_for_region1; + SELECT concat('ALTER TABLE ', table_schema, '.', table_name, ' PLACEMENT POLICY=', @region_name, ';') FROM information_schema.tables WHERE table_schema NOT IN ('METRICS_SCHEMA', 'PERFORMANCE_SCHEMA', 'INFORMATION_SCHEMA','mysql'); + ``` + +## 监控集群 + +对于部署的集群，你可以通过访问集群中的 Grafana 地址或者 TiDB Dashboard 组件来对集群中的各个 TiKV、TiDB 和 PD 组件的各种性能指标进行监控。根据组件的状态，确定是否进行容灾切换。详细信息，请参考如下文档： + +- [TiDB 重要监控指标详解](/grafana-tidb-dashboard.md) +- [TiKV 监控指标详解](/grafana-tikv-dashboard.md) +- [PD 重要监控指标详解](/grafana-pd-dashboard.md) +- [TiDB Dashboard 监控页面](/dashboard/dashboard-monitoring.md) + +## 容灾切换 + +本部分介绍容灾切换，包括计划内切换和计划外切换。 + +### 计划内切换 + +指根据维护需要进行的主备区域切换，可用于验证容灾系统是否可以正常工作。本部分介绍如何在计划内切换主备区域。 + +1. 执行如下命令，将所有用户表和 PD Leader 都切换到区域 2： + + ```sql + -- 将之前创建的规则 secondary_rule_for_region2 应用到对应的用户表上。 + ALTER TABLE tpcc.warehouse PLACEMENT POLICY=secondary_rule_for_region2; + ALTER TABLE tpcc.district PLACEMENT POLICY=secondary_rule_for_region2; + ``` + + 说明：请根据需要修改上面的数据库名称、表名和 placement rule 的名称。 + + 执行如下命令，调低区域 1 的 PD 节点的优先级，并调高区域 2 的 PD 节点的优先级。 + + ``` shell + tiup ctl:v6.4.0 pd member leader_priority pd-1 2 + tiup ctl:v6.4.0 pd member leader_priority pd-2 1 + tiup ctl:v6.4.0 pd member leader_priority pd-3 4 + tiup ctl:v6.4.0 pd member leader_priority pd-4 3 + ``` + +2. 观察 Grafana 中 PD 和 TiKV 部分中的内容，确保 PD 的 Leader 和用户表的 Leader 已经迁移到对应的区域。另外，切换回原有区域的步骤与上面的步骤基本相同，本文不做过多的描述。 + +### 计划外切换 + +计划外切换，指灾难发生时的主备区域切换，或者为了验证容灾系统的有效性，而模拟灾难发生时的主备区域切换。 + +1. 执行类似下面的命令终止区域 1 上所有的 TiKV、TiDB 和 PD 节点: + + ``` shell + tiup cluster stop drtest -N tidb-dr-test1:20160,tidb-dr-test2:20160,tidb-dr-test1:2379,tidb-dr-test2:2379 + ``` + +2. 运行类似于下面的命令切换用户表的 leader 到区域 2: + + ```sql + -- 将之前创建的规则 secondary_rule_for_region2 应用到对应的用户表上。 + ALTER TABLE tpcc.warehouse PLACEMENT POLICY=secondary_rule_for_region2; + ALTER TABLE tpcc.district PLACEMENT POLICY=secondary_rule_for_region2; + + ---可以使用类似下面的查询查看每个区域包含的 leader 数量，以确认 leader 迁移是否完成。 + SELECT STORE_ID, address, leader_count, label FROM TIKV_STORE_STATUS ORDER BY store_id; + ``` + + 当区域 1 恢复正常之后，可以使用类似于上面的命令将用户表的 leader 重新切换到区域 1。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md new file mode 100644 index 000000000000..6601f83b3e32 --- /dev/null +++ b/dr-secondary-cluster.md @@ -0,0 +1,413 @@ +--- +title: 基于主备集群的容灾方案 +summary: 了解如何使用 TiCDC 构建主备集群进行容灾。 +--- + +# 基于主备集群的容灾方案 + +使用主、备数据库进行容灾是一种常用的容灾方式。在这种方案下，系统有一个主用集群和一个备用集群。主集群用于处理用户的请求，备集群负责备份主集群的数据。当主集群发生故障时，系统可以切换到备集群，使用备份的数据继续提供服务。这样，系统就可以在发生故障的情况下继续正常运行，避免因为故障而导致的服务中断。 + +主备集群容灾方案具有如下优势： + +- 高可用性：主、备集群的架构可以有效提高系统的可用性，使得系统在遇到故障时能够快速恢复。 +- 快速切换：在主集群发生故障的情况下，系统可以快速切换到备用集群，继续提供服务。 +- 数据一致性：备用集群会近实时备份主集群的数据，因此，在故障发生后切换到备集群时，数据基本是最新的。 + +本文包含以下主要内容： + +- 构建主备集群 +- 从主集群复制数据至备集群 +- 监控集群 +- 容灾切换 + +同时，本文还介绍了如何在备用集群上进行业务查询，以及如何在主备集群间进行双向同步。 + +## 基于 TiCDC 构建 TiDB 主备集群 + +### 架构概览 + +![TiCDC secondary cluster architecture](/media/dr/dr-ticdc-secondary-cluster.png) + +上述架构包含两个 TiDB 集群：Primary Cluster 和 Secondary Cluster。 + +- Primary Cluster：主用集群，运行在区域 1 (Region 1)，三副本，用于处理读写业务。 +- Secondary Cluster：备用集群，运行在区域 2 (Region 2)，通过 TiCDC 从 Primary Cluster 同步数据。 + +这种容灾架构简洁易用，可以容忍区域级别的故障，既可以保证主用集群的写入性能不会下降，还可以在备用集群处理一些延迟不敏感的只读业务。该方案的 Recovery Point Objective (RPO) 在秒级别，Recovery Time Objective (RTO) 可以达到分钟级别甚至更低。这个方案适用于重要的生产系统。 + +> **注意：** +> +> 不要使用多个 TiCDC Changefeed 同步数据至备用集群，也不要在备用集群基础上运行另一个备用集群，否则，备用集群的数据事务完整性无法保证。 + +### 搭建主备集群 + +本文将 TiDB 主集群和备用集群分别部署在两个不同的区域（区域 1 和区域 2）。由于主备集群之间存在一定的网络延迟，TiCDC 与 TiDB 备用集群应部署在一起，以实现最好的数据同步性能。在本教程示例中，每台服务器部署一个组件节点，具体的部署拓扑如下： + +|区域 | 主机 | 集群 | 组件 | +| --- | --- | --- | --- | +| 区域 1 | 10.0.1.1/10.0.1.2/10.0.1.3 | Primary | PD | +| 区域 1 | 10.0.1.4/10.0.1.5 | Primary| TiDB | +| 区域 1 | 10.0.1.6/10.0.1.7/10.0.1.8 | Primary | TiKV | +| 区域 1 | 10.0.1.9 | Primary | Monitor、Grafana 或 AlterManager | +| 区域 2 | 10.1.1.9/10.1.1.10 | Primary | TiCDC | +| 区域 2 | 10.1.1.1/10.1.1.2/10.1.1.3 | Secondary | PD | +| 区域 2 | 10.1.1.4/10.1.1.5 | Secondary | TiDB | +| 区域 2 | 10.1.1.6/10.1.1.7/10.1.1.8 | Secondary | TiKV | +| 区域 2 | 10.0.1.11 | Secondary | Monitor、Grafana 或 AlterManager | + +关于服务器配置信息，可以参考如下文档： + +- [TiDB 软件和硬件环境建议配置](/hardware-and-software-requirements.md) +- [TiCDC 软件和硬件环境推荐配置](/ticdc/deploy-ticdc.md#软件和硬件环境推荐配置) + +部署 TiDB 主集群和备用集群的详细过程，可以参考[部署 TiDB 集群](/production-deployment-using-tiup.md)。 + +部署 TiCDC 组件需要注意的是，Secondary Cluster 和 TiCDC 需要在一起部署和管理，并且它们之间的网络需要能够连通。 + +- 如果需要在已有的 Primary Cluster 上部署 TiCDC，请参考[部署 TiCDC 组件](/ticdc/deploy-ticdc.md#使用-tiup-在原有-tidb-集群上新增或扩容-ticdc-组件)。 +- 如果部署全新的 Primary Cluster 和 TiCDC 组件，则可以使用以下 TiUP 部署模版，并按照需要修改配置参数： + + ```yaml + global: + user: "tidb" + ssh_port: 22 + deploy_dir: "/tidb-deploy" + data_dir: "/tidb-data" + server_configs: {} + pd_servers: + - host: 10.0.1.1 + - host: 10.0.1.2 + - host: 10.0.1.3 + tidb_servers: + - host: 10.0.1.4 + - host: 10.0.1.5 + tikv_servers: + - host: 10.0.1.6 + - host: 10.0.1.7 + - host: 10.0.1.8 + monitoring_servers: + - host: 10.0.1.9 + grafana_servers: + - host: 10.0.1.9 + alertmanager_servers: + - host: 10.0.1.9 + cdc_servers: + - host: 10.1.1.9 + gc-ttl: 86400 + data_dir: "/cdc-data" + ticdc_cluster_id: "DR_TiCDC" + - host: 10.1.1.10 + gc-ttl: 86400 + data_dir: "/cdc-data" + ticdc_cluster_id: "DR_TiCDC" + ``` + +### 从主集群复制数据到备用集群 + +搭建好 TiDB 主集群和备用集群之后，需要先将主集群的数据迁移到备用集群，然后创建同步任务从主集群复制实时变更数据到备用集群。 + +#### 选择外部存储 + +数据迁移和实时变更数据复制都需要使用外部存储。推荐使用 Amazon S3 作为存储系统。如果 TiDB 集群部署在自建机房中，则推荐以下方式： + +* 搭建 [MinIO](https://docs.min.io/docs/minio-quickstart-guide.html) 作为备份存储系统，使用 S3 协议将数据备份到 MinIO 中。 +* 挂载 NFS 盘（如 NAS）到 br、TiKV 和 TiCDC 实例节点，使用 POSIX 文件系统接口将备份数据写入对应的 NFS 目录中。 + +下面以 MinIO 为示例，仅供参考。注意需要在区域 1 或者区域 2 中准备独立的服务器部署 MinIO。 + +```shell +wget https://dl.min.io/server/minio/release/linux-amd64/minio +chmod +x minio +# 配置访问 MinIO 的 access-key 和 access-secret-id +export HOST_IP='10.0.1.10' # 替换为实际部署 MinIO 的机器 IP 地址 +export MINIO_ROOT_USER='minio' +export MINIO_ROOT_PASSWORD='miniostorage' +# 创建 TiCDC redo log 和 backup 数据保存的目录，其中 redo、backup 为 bucket 名字 +mkdir -p data/redo +mkdir -p data/backup +# 启动 MinIO，暴露端口在 6060 +nohup ./minio server ./data --address :6060 & +``` + +上述命令启动了一个单节点的 MinIO server 模拟 S3 服务，相关参数为： + +* `endpoint`：`http://10.0.1.10:6060/` +* `access-key`：`minio` +* `secret-access-key`：`miniostorage` +* `bucket`：`redo`/`backup` + +其访问链接为： + +``` +s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true +``` + +#### 数据迁移 + +在 TiDB 主备集群之间使用 [TiDB 备份恢复功能 BR](/br/backup-and-restore-overview.md) 进行数据迁移。 + +1. 关闭垃圾回收机制 (GC)。为了保证增量迁移过程中新写入的数据不丢失，在开始备份之前，需要关闭上游集群的 GC 机制，以确保系统不再清理历史数据。 + + 执行如下命令关闭 GC： + + ```sql + SET GLOBAL tidb_gc_enable=FALSE; + ``` + + 查询 `tidb_gc_enable` 的取值，以确认 GC 是否已关闭： + + ```sql + SELECT @@global.tidb_gc_enable; + ``` + + 输出结果为 `0` 表明 GC 已关闭： + + ``` + +-------------------------+ + | @@global.tidb_gc_enable | + +-------------------------+ + | 0 | + +-------------------------+ + 1 row in set (0.00 sec) + ``` + + > **注意：** + > + > 在生产集群中，关闭 GC 机制和备份操作会一定程度上降低集群的读性能。建议在业务低峰期进行备份，并设置合适的 `RATE_LIMIT` 限制备份操作对线上业务的影响。 + +2. 备份数据。在 TiDB 主集群中执行 `BACKUP` 语句备份数据： + + ```sql + BACKUP DATABASE * TO '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true`'; + ``` + + ``` + +----------------------+----------+--------------------+---------------------+---------------------+ + | Destination | Size | BackupTS | Queue Time | Execution Time | + +----------------------+----------+--------------------+---------------------+---------------------+ + | s3://backup | 10315858 | 431434047157698561 | 2022-02-25 19:57:59 | 2022-02-25 19:57:59 | + +----------------------+----------+--------------------+---------------------+---------------------+ + 1 row in set (2.11 sec) + ``` + + 备份语句提交成功后，TiDB 会返回关于备份数据的元信息，这里需要重点关注 `BackupTS`，它意味着该时间点之前的数据会被备份。本文后续步骤中，使用 `BackupTS` 作为**实时变更数据复制的起始时间点**。 + +3. 恢复数据。在 TiDB 备用集群中执行 `RESTORE` 语句恢复数据： + + ```sql + RESTORE DATABASE * FROM '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true`'; + ``` + + ``` + +----------------------+----------+----------+---------------------+---------------------+ + | Destination | Size | BackupTS | Queue Time | Execution Time | + +----------------------+----------+----------+---------------------+---------------------+ + | s3://backup | 10315858 | 0 | 2022-02-25 20:03:59 | 2022-02-25 20:03:59 | + +----------------------+----------+----------+---------------------+---------------------+ + 1 row in set (41.85 sec) + ``` + +#### 复制实时变更数据 + +完成以上数据迁移的操作步骤后，从备份的 **BackupTS** 时间点开始同步主集群增量变更数据到备用集群。 + +1. 创建 TiCDC 同步任务 Changefeed。 + + 创建 Changefeed 配置文件并保存为 `changefeed.toml`。 + + ```toml + [consistent] + # eventual consistency：使用 redo log，提供上游灾难情况下的最终一致性。 + level = "eventual" + # 单个 redo log 文件大小，单位 MiB，默认值 64，建议该值不超过 128。 + max-log-size = 64 + # 刷新或上传 redo log 至 S3 的间隔，单位毫秒，默认 1000，建议范围 500-2000。 + flush-interval = 2000 + # 存储 redo log 的地址 + storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true" + ``` + + 在主用集群中，执行以下命令创建从主用集群到备用集群的同步链路： + + ```shell + tiup cdc cli changefeed create --server=http://10.1.1.9:8300 --sink-uri="mysql://{username}:{password}@10.1.1.4:4000" --changefeed-id="dr-primary-to-secondary" --start-ts="431434047157698561" + ``` + + 更多关于 Changefeed 的配置，请参考 [TiCDC Changefeed 配置参数](/ticdc/ticdc-changefeed-config.md)。 + +2. 查询 Changefeed 是否正常运行。使用 `changefeed query` 命令可以查询特定同步任务（对应某个同步任务的信息和状态），指定 `--simple` 或 `-s` 参数会简化输出，提供基本的同步状态和 checkpoint 信息。不指定该参数会输出详细的任务配置、同步状态和同步表信息。 + + ```shell + tiup cdc cli changefeed query -s --server=http://10.1.1.9:8300 --changefeed-id="dr-primary-to-secondary" + ``` + + ```shell + { + "state": "normal", + "tso": 431434047157998561, # changefeed 已经同步到的时间点 + "checkpoint": "2020-08-27 10:12:19.579", # TSO 对应的物理时间点 + "error": null + } + ``` + +3. 重新开启 GC。 + + TiCDC 可以保证未同步的历史数据不会被回收。因此，创建完从主集群到备用集群的 Changefeed 之后，就可以执行如下命令恢复集群的垃圾回收功能。 + + 执行如下命令打开 GC： + + ```sql + SET GLOBAL tidb_gc_enable=TRUE; + ``` + + 查询 `tidb_gc_enable` 的取值，判断 GC 是否已开启： + + ```sql + SELECT @@global.tidb_gc_enable; + ``` + + 结果输出 `1` 表明 GC 已开启： + + ``` + +-------------------------+ + | @@global.tidb_gc_enable | + +-------------------------+ + | 1 | + +-------------------------+ + 1 row in set (0.00 sec) + ``` + +### 主备集群状态监控 + +TiDB 目前还没有提供 DR Dashboard，你可以通过以下 Dashboard 了解 TiDB 主备集群的状态，从而决定是否需要进行容灾切换： + +- [TiDB 集群运行状态 Dashboard](/grafana-overview-dashboard.md) +- [Changefeed 运行状态](/ticdc/monitor-ticdc.md#changefeed-面板) + +### 容灾切换 + +本部分介绍容灾演练，遇到真正灾难时的主备切换，以及重建灾备集群的步骤。 + +#### 计划中的主备切换 + +定期对非常重要的业务系统进行容灾演练，检验系统的可靠性是非常有必要的。下面是容灾演练推荐的操作步骤，因为没有考虑演练中业务写入是否为模拟、业务访问数据库是否使用 proxy 服务等，与实际的演练场景会有出入，请根据你的实际情况进行修改。 + +1. 停止主集群上的业务写入。 +2. 业务写入完全停止后，查询 TiDB 集群当前最新的 TSO (`Position`)： + + ```sql + mysql> show master status; + +-------------+--------------------+--------------+------------------+-------------------+ + | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | + +-------------+--------------------+--------------+------------------+-------------------+ + | tidb-binlog | 438223974697009153 | | | | + +-------------+--------------------+--------------+------------------+-------------------+ + 1 row in set (0.33 sec) + ``` + +3. 轮询 Changefeed `dr-primary-to-secondary` 的同步位置时间点 TSO 直到满足 `TSO >= Position`。 + + ```shell + tiup cdc cli changefeed query -s --server=http://10.1.1.9:8300 --changefeed-id="dr-primary-to-secondary" + + { + "state": "normal", + "tso": 438224029039198209, # Changefeed 已经同步到的时间点 + "checkpoint": "2022-12-22 14:53:25.307", # TSO 对应的物理时间点 + "error": null + } + ``` + +4. 停止 Changefeed `dr-primary-to-secondary`。通过删除 Changefeed 的方式，暂停 Changefeed `dr-primary-to-secondary`： + + ```shell + tiup cdc cli changefeed remove --server=http://10.1.1.9:8300 --changefeed-id="dr-primary-to-secondary" + ``` + +5. 创建 Changefeed `dr-secondary-to-primary`。不需要指定 Changefeed `start-ts` 参数，Changefeed 从当前时间开始同步即可。 +6. 修改业务应用的数据库访问配置，并重启业务应用，使得业务访问备用集群。 +7. 检查业务状态是否正常。 + +容灾演练后，再重复一遍以上步骤，即可恢复原有的系统主备配置。 + +#### 真正灾难中主备切换 + +当发生真正的灾难，比如主集群所在区域停电，主备集群的同步链路可能会突然中断，从而导致备用集群数据处于事务不一致的状态。 + +1. 恢复备用集群到事务一致的状态。在区域 2 的任意 TiCDC 节点执行以下命令，以向备用集群重放 redo log，使备用集群达到最终一致性状态： + + ```shell + tiup cdc redo apply --storage "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true" --tmp-dir /tmp/redo --sink-uri "mysql://{username}:{password}@10.1.1.4:4000" + ``` + + 命令中参数描述如下： + + - `--storage`：指定 redo log 所在的 S3 位置 + - `--tmp-dir`：为从 S3 下载 redo log 的缓存目录 + - `--sink-uri`：指定备份集群的地址 + +2. 修改业务应用的数据库访问配置，并重启业务应用，使得业务访问备用集群。 +3. 检查业务状态是否正常。 + +#### 灾难后重建主备集群 + +当 TiDB 主集群所遭遇的灾难解决后，或者主集群暂时不能恢复，此时 TiDB 集群是脆弱的，只有一个备用集群临时作为新的主集群提供服务。为了维持系统的可靠性，需要重建灾备集群保护系统的可靠性。 + +目前，重建 TiDB 主备集群，通用的方案是重新部署一个新的集群，组成新的容灾主备集群。操作请参考： + +1. [搭建主备集群](#搭建主备集群)。 +2. [从主集群复制数据到备用集群](#从主集群复制数据到备用集群)。 +3. 完成以上操作步骤后，如果你希望新集群成为主集群，那么请参考[主从切换](#计划中的主备切换)。 + +> **注意：** +> +> 如果在业务上能够修正灾难发生后主集群和备用集群的数据不一致的问题，那么也可以使用修正后的集群重建主备集群，而不需要重建新集群。 + +### 在备用集群上进行业务查询 + +在主备集群容灾场景中，将备用集群作为只读集群来运行一些延迟不敏感的查询是常见的需求，TiDB 主备集群容灾方案也提供了这种功能。 + +创建 Changefeed 时，你只需要在配置文件中开启 Syncpoint 功能，Changefeed 就会定期 (`sync-point-interval`) 在备用集群中通过执行 `SET GLOBAL tidb_external_ts = @@tidb_current_ts` 设置已复制完成的一致性快照点。 + +当业务需要从备用集群查询数据的时候，在业务应用中设置 `SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;` 就可以在备用集群上获得事务状态完成的数据。 + +```toml +# 从 v6.4.0 开始支持，使用 Syncpoint 功能需要同步任务拥有下游集群的 SYSTEM_VARIABLES_ADMIN 或者 SUPER 权限 +enable-sync-point = true + +# 记录主集群和备用集群一致快照点的时间间隔，它也代表能读到完整事务的最大延迟时间，比如在备用集群读取到主集群两分钟之前的事务数据 +# 配置格式为 h m s，例如 "1h30m30s"。默认值为 10m，最小值为 30s +sync-point-interval = "10m" + +# Syncpoint 功能在下游表中保存的数据的时长，超过这个时间的数据会被清理 +# 配置格式为 h m s，例如 "24h30m30s"。默认值为 24h +sync-point-retention = "1h" + +[consistent] +# eventual consistency： 使用 redo log，提供上游灾难情况下的最终一致性。 +level = "eventual" +# 单个 redo log 文件大小，单位 MiB，默认值 64，建议该值不超过 128。 +max-log-size = 64 +# 刷新或上传 redo log 至 S3 的间隔，单位毫秒，默认 1000，建议范围 500-2000。 +flush-interval = 2000 +# 存储 redo log +storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true" +``` + +> **注意：** +> +> 在主备集群容灾架构中，每个备用集群只能被一个 Changefeed 同步数据，否则就无法保证备用集群的事务完整性。 + +### 在主备集群之间进行双向复制 + +在主备集群容灾场景中，部分用户希望让两个区域的 TiDB 集群互为灾备集群：用户的业务流量按其区域属性写入对应的 TiDB 集群，同时两套 TiDB 集群备份对方集群的数据。 + +![TiCDC bidirectional replication](/media/dr/bdr-ticdc.png) + +在双向复制容灾集群方案中，两个区域的 TiDB 集群互相备份对方的数据，使得它们可以在故障发生时互为灾备集群。这种方案既能满足安全性和可靠性的需求，同时也能保证数据库的写入性能。在计划中的主备切换场景中，不需要停止正在运行的 Changefeed 和启动新的 Changefeed 等操作，在运维上也更加简单。 + +搭建双向容灾复制集群的步骤，请参考教程 [TiCDC 双向复制](/ticdc/ticdc-bidirectional-replication.md)。 + +## 常见问题处理 + +以上任何步骤遇到问题，可以先通过 [TiDB FAQ](/faq/faq-overview.md) 查找问题的处理方法。如果问题仍不能解决，请在 TiDB 项目中提 [issue](https://github.com/pingcap/tidb/issues/new/choose)。 diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md new file mode 100644 index 000000000000..75ad261f82b6 --- /dev/null +++ b/dr-solution-introduction.md @@ -0,0 +1,113 @@ +--- +title: TiDB 容灾方案概述 +summary: 了解 TiDB 提供的几种容灾方案，包括基于主备集群的容灾、基于多副本的单集群容灾和基于备份与恢复的容灾。 +--- + +# TiDB 容灾方案概述 + +本文将以如下结构系统介绍 TiDB 容灾解决方案： + +- 介绍容灾解决方案涉及的基本概念。 +- 介绍核心组件 TiDB、TiCDC 及 BR 的架构。 +- 介绍各种容灾方案。 +- 对比不同的容灾解决方案。 + +## 基本概念 + +- RTO (Recovery Time Objective)：是指灾难发生后，系统恢复服务所需的时间。 +- RPO (Recovery Point Objective)：是指灾难发生后，确保对业务不产生损失的前提下，可以丢失的最大数据量。 + +下面的图形描述了这两个概念： + +![RTO and RPO](/media/dr/rto-rpo.png) + +- 错误容忍目标：由于灾难可能影响的地域范围是不同的，在本文中，使用“错误容忍目标”来描述系统能够容忍的灾难的最大范围。 +- 区域：本文主要讨论区域 (region) 级别的容灾方案，这里的区域通常是指一个物理世界中的地区或者城市。 + +## 组件架构 + +在介绍具体的容灾方案之前，本部分将从容灾角度介绍容灾系统中的组件架构，包括 TiDB、TiCDC 和 BR。 + +### TiDB 架构 + +![TiDB architecture](/media/dr/tidb-architecture.png) + +TiDB 的设计采用了计算、存储分离的架构： + +- TiDB 为系统的计算层。 +- TiKV 是系统的存储层，采用行存的方式保存数据库的数据记录，其中 [Region](/glossary.md#regionpeerraft-group) 是经过排序的若干行数据的集合，也是系统调度数据的单位。同一个 Region 的数据保存至少 3 份，通过 Raft 协议在日志层复制数据改变。 +- TiFlash 副本是可选的，它是一款列式存储，用于加速分析类查询的速度。数据通过 Raft group 中的 learner 角色与 TiKV 中的数据进行复制。 + +由于 TiDB 保存了三份完整的数据副本，所以天然就具备了基于多副本数据复制的容灾能力。同时，由于 TiDB 采用了 Raft log 来进行事务日志同步，也在一定程度上具备了基于事务日志同步的容灾能力。 + +### TiCDC 架构 + +![TiCDC architecture](/media/ticdc/cdc-architecture.png) + +TiCDC 作为 TiDB 的增量数据同步工具，通过 PD 内部的 etcd 实现高可用，通过多个 Capture 进程获取 TiKV 节点上的数据改变，在内部进行排序、合并等处理之后，通过多个同步任务，同时向多个下游系统进行数据同步。在上面的架构中： + +- TiKV server：负责将对应节点上数据的改变推送到TiCDC 节点。当然，如果 TiCDC 发现收到的数据改变不完整，也会主动联系 TiKV server 获取需要的数据改变。 +- TiCDC：负责启动多个 Capture 进程，每个 Capture 负责拉取一部分的 KV change logs，并对获取到的数据改变进行排序，最后同步到不同的下游当中。 + +从上面的架构中可以看到，TiCDC 的架构和事务日志复制系统比较类似，但是扩展性更好，同时又兼顾了逻辑数据复制的很多特点。所以，TiCDC 也可以为 TiDB 在容灾场景提供很好的帮助和补充。 + +### BR 架构 + +![BR architecture](/media/br/br-snapshot-arch.png) + +BR 作为 TiDB 的备份恢复工具，可以对 TiDB 集群进行基于时间点的全量快照备份和持续的日志备份，从而保护 TiDB 集群的数据。当 TiDB 集群完全不可用时，可以通过备份文件，在全新的集群中进行恢复。备份恢复通常是数据安全的最后一道防线。 + +## 方案介绍 + +### 基于 TiCDC 的主备集群容灾方案 + +![Primary-secondary cluster DR](/media/dr/ticdc-dr.png) + +在上面的架构中包含了两个 TiDB 集群，Cluster1 为主用集群，运行在区域 1 (Region 1)，包含 3 个副本，承担读写业务。Cluster2 作为灾备集群，运行在区域 2 (Region 2)。当 Cluster1 出现灾难时，Cluster2 继续对外提供服务。两个集群之间通过 TiCDC 进行数据改变的同步。这种架构，简称为“1:1”解决方案。 + +这种架构看起来非常简洁，可用性比较高，最大的错误容忍目标可以做到区域级别，写能力也能够得到扩展，RPO 在秒级别，RTO 在分钟级别，甚至更低。如果 RPO 为 0 并不是必须满足的要求，推荐在重要生产系统使用该容灾方案。对于该方案的详细信息，请参考[基于主备集群的容灾方案](/dr-secondary-cluster.md)。 + +### 基于多副本的单集群容灾方案 + +![Multi-replica cluster DR](/media/dr/multi-replica-dr.png) + +在上面的架构中，每个区域都包含两份完整的数据副本，它们位于不同的可用区 (Available Zone, AZ) 当中（通常情况下，两个可用区之间的网络速度和带宽条件较好，在同一个区域中的不同 AZ 中读写请求的延迟很低），整个集群横跨了三个区域。区域 1 通常是用来处理读写业务请求的主区域，当区域 1 出现灾难后完全不可用时，区域 2 可以作为灾难恢复的区域。而区域 3 (Region 3) 更多的是为了满足多数派协议而存在的一个副本。这种架构，简称为“2-2-1”解决方案。 + +该方案最大的错误容忍目标可以达到区域级别，写能力也能够得到扩展，并且 RPO 为 0，RTO 也可以达到分钟级别，甚至更低。如果 RPO 为 0 是必须满足的要求，推荐在重要生产系统使用该容灾方案。对于该方案的详细信息，请参考[基于多副本的单集群容灾方案](/dr-multi-replica.md)。 + +### 多副本与 TiCDC 相结合的容灾解决方案 + +以上两种容灾解决方案都可以实现区域级别的容灾，但是都无法解决多个区域同时不可用的问题。如果你的系统非常重要，需要“错误容忍目标”达到多个区域，就需要将以上两种容灾解决方案进行结合。 + +![TiCDC-based multi-replica cluster DR](/media/dr/ticdc-multi-replica-dr.png) + +在上面的部署中存在两个 TiDB 集群。Cluster1 有 5 个副本，跨 3 个区域。区域 1 (Region 1) 包含两个副本作为主区域，用于服务写入。区域 2 (Region 2) 有两个副本作为区域 1 的容灾区域，可以提供一些延迟不敏感的读取服务。最后一个副本用于投票，位于区域 3 (Region 3) 中。 + +作为区域 1 和区域 2 的容灾集群，Cluster2 在区域 3 中运行，并包含 3 个副本。TiCDC 在两个集群之间同步数据更改。这种部署可能看起来比较复杂，但它可以将容错目标提高到多区域。如果多区域故障不要求 RPO 必须为 0，这种架构是一个很好的选择。这种架构，简称为 “2-2-1:1” 解决方案。 + +当然，如果“错误容忍目标”为多个区域，并且 RPO 为 0 是一个必须满足的要求，你也可以考虑创建一个包含至少 9 个副本，横跨 5 个区域的集群来实现该能力。这种架构，简称为“2-2-2-2-1”解决方案。 + +### 基于备份与恢复的容灾解决方案 + +![BR-based cluster DR](/media/dr/br-dr.png) + +按照上面的部署，TiDB Cluster1 部署在区域 1 (Region 1)，BR 工具定期将集群的数据备份到区域 2 (Region 2)，并且持续将数据改变日志也备份到区域 2。当区域 1 出现灾难导致 Cluster1 无法恢复时，你可以使用备份的数据和数据改变在区域 2 恢复新的集群 Cluster2 对外提供服务。 + +基于备份恢复的容灾方案，目前，RPO 低于 5 分钟，而 RTO 则取决于需要恢复的集群数据大小，对于 v6.5.0 版本的 BR，其恢复速度可以参考[快照恢复的性能与影响](/br/br-snapshot-guide.md#快照恢复的性能与影响)和 [PITR 的性能与影响](/br//br-pitr-guide.md#pitr-的性能与影响)。通常来说，大部分客户会把跨区域 的备份作为数据安全的最后一道防线，是大多数系统都需要的。对于该方案的详细信息，请参考[基于备份与恢复的容灾方案](/dr-backup-restore.md)。 + +另外，从 v6.5.0 开始，BR 支持[基于 AWS 上的 EBS 快照的快速恢复](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/restore-from-aws-s3-by-snapshot)。如果你在 AWS 上运行 TiDB 集群，要求备份过程对集群没有任何影响，并且要求恢复的时间尽量短，可以考虑使用该特性来降低系统的 RTO。 + +### 其他容灾解决方案 + +除了以上容灾方案，针对同城双中心这种特定的场景，如果 RPO=0 是一个必须的条件，你也可以采用 DR-AUTO sync 解决方案。详细的信息请参考[单区域双 AZ 部署 TiDB](/two-data-centers-in-one-city-deployment.md)。 + +## 方案对比 + +最后，对本文提到的各种容灾解决方案进行对比，以方便你根据自己的业务需要选择合适的容灾方案。 + +| 容灾方案 | TCO | 错误容忍目标 | RPO | RTO | 网络延迟要求 | 使用的系统 | +| --- | --- | --- | --- | --- | --- | --- | +| 基于多副本的单集群容灾方案 (2-2-1) | 高 | 单个区域 | 0 | 分钟级 | 区域之间的网络延迟要求小于 30 ms。 | 对灾备和响应时间有明确要求 (RPO = 0) 的重要生产系统。 | +| 基于 TiCDC 的主备集群容灾方案 (1:1) | 中等 | 单个区域 | 小于 10 秒 | 小于 5 分钟 | 区域之间的网络延迟要求小于 100 ms。 | 对灾备和响应时间有明确要求 (RPO > 0) 的重要生产系统。 | +| 多副本与 TiCDC 相结合的容灾解决方案 (2-2-1:1) | 高 | 多个区域 | 小于 10 秒 | 小于 5 分钟 | 对于通过多副本进行容灾的区域，网络延迟建议小于 30 ms。对于第三区域与其他区域之间，建议延迟小于 100 ms。 | 对灾难恢复和响应时间有严格要求的关键生产系统。 | +| 基于备份恢复的容灾方案 | 低 | 单个区域 | 小于 5 分钟 | 小时级 | 无特殊要求 | 能够接受 RPO < 5 分钟，RTO 达到小时级别的系统。 | diff --git a/media/dr/bdr-ticdc.png b/media/dr/bdr-ticdc.png new file mode 100644 index 000000000000..014db691640d Binary files /dev/null and b/media/dr/bdr-ticdc.png differ diff --git a/media/dr/br-dr.png b/media/dr/br-dr.png new file mode 100644 index 000000000000..fa0bac432977 Binary files /dev/null and b/media/dr/br-dr.png differ diff --git a/media/dr/dr-backup-and-restore.png b/media/dr/dr-backup-and-restore.png new file mode 100644 index 000000000000..f7099a21b65b Binary files /dev/null and b/media/dr/dr-backup-and-restore.png differ diff --git a/media/dr/dr-ticdc-secondary-cluster.png b/media/dr/dr-ticdc-secondary-cluster.png new file mode 100644 index 000000000000..d4abe1876a38 Binary files /dev/null and b/media/dr/dr-ticdc-secondary-cluster.png differ diff --git a/media/dr/multi-replica-dr.png b/media/dr/multi-replica-dr.png new file mode 100644 index 000000000000..9d33074351fe Binary files /dev/null and b/media/dr/multi-replica-dr.png differ diff --git a/media/dr/rto-rpo.png b/media/dr/rto-rpo.png new file mode 100644 index 000000000000..0837c431f9bb Binary files /dev/null and b/media/dr/rto-rpo.png differ diff --git a/media/dr/ticdc-dr.png b/media/dr/ticdc-dr.png new file mode 100644 index 000000000000..d15bf2440d97 Binary files /dev/null and b/media/dr/ticdc-dr.png differ diff --git a/media/dr/ticdc-multi-replica-dr.png b/media/dr/ticdc-multi-replica-dr.png new file mode 100644 index 000000000000..4020fccba812 Binary files /dev/null and b/media/dr/ticdc-multi-replica-dr.png differ diff --git a/media/dr/tidb-architecture.png b/media/dr/tidb-architecture.png new file mode 100644 index 000000000000..c451d056e203 Binary files /dev/null and b/media/dr/tidb-architecture.png differ