diff --git a/latest_translation_commit.json b/latest_translation_commit.json index f80540feed763..576c0ab11a645 100644 --- a/latest_translation_commit.json +++ b/latest_translation_commit.json @@ -1,4 +1,4 @@ { "target": "release-8.5", - "sha": "74b90d9c056eddbddcaebba7f184861b64b25aee" + "sha": "797251ecc59fbe2263fec7e80b38d3944c2c0742" } \ No newline at end of file diff --git a/tidb-architecture.md b/tidb-architecture.md index cbb9d35f63ccb..6445eb6101921 100644 --- a/tidb-architecture.md +++ b/tidb-architecture.md @@ -5,51 +5,57 @@ summary: TiDB 平台的关键架构组件 # TiDB 架构 + + +TiDB 提供两种架构：经典 TiDB 架构和 [TiDB X 架构](/tidb-cloud/tidb-x-architecture.md)。本文介绍经典 TiDB 架构。 + + + 与传统的单机数据库相比，TiDB 具有以下优势： -* 具有分布式架构，具有灵活和弹性的扩展能力。 -* 完全兼容 MySQL 协议、MySQL 的常用功能和语法。要将你的应用迁移到 TiDB，在大多数情况下无需修改一行代码。 -* 支持高可用性，出现少数副本故障时自动故障转移；对应用透明。 -* 支持 ACID 事务，适用于需要强一致性的场景，如银行转账。 +* 拥有分布式架构，具备灵活和弹性的扩展性。 +* 完全兼容 MySQL 协议、MySQL 的常用特性和语法。在许多情况下，应用迁移到 TiDB 无需修改一行代码。 +* 支持高可用，当少数副本故障时可自动故障转移，对应用透明。 +* 支持 ACID 事务，适用于如银行转账等需要强一致性的场景。 -* 提供丰富的 [数据迁移工具](/migration-overview.md)，用于迁移、复制或备份数据。 +* 提供丰富的 [数据迁移工具](/migration-overview.md) 用于数据迁移、同步或备份。 -作为一个分布式数据库，TiDB 设计为由多个组件组成。这些组件相互通信，形成一个完整的 TiDB 系统。架构如下： +作为分布式数据库，TiDB 由多个组件组成。这些组件之间相互通信，形成完整的 TiDB 系统。架构如下所示： -![TiDB 架构](/media/tidb-architecture-v6.png) +![TiDB Architecture](/media/tidb-architecture-v6.png) -## TiDB 服务器 +## TiDB server -[TiDB 服务器](/tidb-computing.md) 是一个无状态的 SQL 层，向外部暴露 MySQL 协议的连接端点。TiDB 服务器接收 SQL 请求，进行 SQL 解析和优化，最终生成分布式执行计划。它具有水平扩展能力，并通过如 TiProxy、Linux Virtual Server (LVS)、HAProxy、ProxySQL 或 F5 等负载均衡组件向外提供统一接口。它不存储数据，仅用于计算和 SQL 分析，将实际的数据读取请求传递给 TiKV 节点（或 TiFlash 节点）。 +[TiDB server](/tidb-computing.md) 是无状态的 SQL 层，向外暴露 MySQL 协议的连接端点。TiDB server 接收 SQL 请求，进行 SQL 解析和优化，最终生成分布式执行计划。它支持水平扩展，并通过 TiProxy、Linux Virtual Server (LVS)、HAProxy、ProxySQL 或 F5 等负载均衡组件对外提供统一接口。TiDB server 不存储数据，仅用于计算和 SQL 分析，将实际的数据读请求转发到 TiKV 节点（或 TiFlash 节点）。 -## Placement Driver (PD) 服务器 +## Placement Driver (PD) server -[PD 服务器](/tidb-scheduling.md) 是整个集群的元数据管理组件。它存储每个 TiKV 节点的实时数据分布元数据和整个 TiDB 集群的拓扑结构，提供 TiDB Dashboard 管理界面，并为分布式事务分配事务 ID。PD 服务器是整个 TiDB 集群的“脑”，因为它不仅存储集群的元数据，还根据 TiKV 节点实时上报的数据分布状态，向特定的 TiKV 节点发送数据调度命令。此外，PD 服务器至少由三个节点组成，具有高可用性。建议部署奇数个 PD 节点。 +[PD server](/tidb-scheduling.md) 是整个集群的元信息管理组件。它存储每个 TiKV 节点的实时数据分布元信息和整个 TiDB 集群的拓扑结构，提供 TiDB Dashboard 管理界面，并为分布式事务分配事务 ID。PD server 是整个 TiDB 集群的“大脑”，不仅存储集群的元信息，还会根据 TiKV 节点实时上报的数据分布状态，向特定 TiKV 节点发送数据调度命令。此外，PD server 至少由三个节点组成，具备高可用性。建议部署奇数个 PD 节点。 ## 存储服务器 -### TiKV 服务器 +### TiKV server -[TiKV 服务器](/tidb-storage.md) 负责存储数据。TiKV 是一个分布式事务性键值存储引擎。 +[TiKV server](/tidb-storage.md) 负责存储数据。TiKV 是分布式事务型键值存储引擎。 -[Region](/glossary.md#regionpeerraft-group) 是存储数据的基本单元。每个 Region 存储特定 Key 范围内的数据，该范围为左闭右开的区间，从 StartKey 到 EndKey。 +[Region](/glossary.md#regionpeerraft-group) 是存储数据的基本单元。每个 Region 存储特定 Key Range 的数据，该范围是一个左闭右开的区间，从 StartKey 到 EndKey。 -[Region](/tidb-cloud/tidb-cloud-glossary.md#region) 是存储数据的基本单元。每个 Region 存储特定 Key 范围内的数据，该范围为左闭右开的区间，从 StartKey 到 EndKey。 +[Region](/tidb-cloud/tidb-cloud-glossary.md#region) 是存储数据的基本单元。每个 Region 存储特定 Key Range 的数据，该范围是一个左闭右开的区间，从 StartKey 到 EndKey。 -每个 TiKV 节点中存在多个 Region。TiKV API 原生支持在键值对层面进行分布式事务，并默认支持 Snapshot Isolation 级别的隔离。这是 TiDB 在 SQL 层支持分布式事务的核心。处理 SQL 语句后，TiDB 服务器会将 SQL 执行计划转换为对 TiKV API 的实际调用。因此，数据存储在 TiKV 中。TiKV 中的所有数据都会自动维护多份副本（默认为三份），因此 TiKV 具有原生的高可用性，并支持自动故障转移。 +每个 TiKV 节点中存在多个 Region。TiKV API 在键值对层面原生支持分布式事务，并默认支持 Snapshot Isolation 级别的隔离。这是 TiDB 在 SQL 层支持分布式事务的核心。TiDB server 在处理 SQL 语句后，会将 SQL 执行计划转化为对 TiKV API 的实际调用。因此，数据存储在 TiKV 中。TiKV 中的所有数据会自动维护多副本（默认三副本），因此 TiKV 原生具备高可用性，并支持自动故障转移。 -### TiFlash 服务器 +### TiFlash server -[TiFlash 服务器](/tiflash/tiflash-overview.md) 是一种特殊类型的存储服务器。不同于普通的 TiKV 节点，TiFlash 以列存储数据，主要用于加速分析处理。 \ No newline at end of file +[TiFlash server](/tiflash/tiflash-overview.md) 是一种特殊类型的存储服务器。与普通 TiKV 节点不同，TiFlash 以列存方式存储数据，主要用于加速分析型处理。 \ No newline at end of file diff --git a/tidb-cloud/changefeed-sink-to-cloud-storage.md b/tidb-cloud/changefeed-sink-to-cloud-storage.md index 4e4d43eb9ee5d..4356d8327c5d5 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -1,26 +1,26 @@ --- title: Sink to Cloud Storage -summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Cloud 的数据流式同步到 Amazon S3 或 GCS。内容包括限制、目标端配置、同步与规范配置，以及启动同步流程。 +summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式同步到 Amazon S3、Google Cloud Storage (GCS) 或 Azure Blob Storage。内容包括限制、目标端配置、同步及规范配置，以及启动同步流程。 --- # Sink to Cloud Storage -本文档介绍如何创建变更订阅（changefeed），将 TiDB Cloud 的数据流式同步到云存储。目前支持 Amazon S3 和 GCS。 +本文档描述如何创建 changefeed，将数据从 TiDB Cloud 流式同步到云存储。目前支持 Amazon S3、Google Cloud Storage (GCS) 和 Azure Blob Storage。 > **注意：** > -> - 若要将数据流式同步到云存储，请确保你的 TiDB 集群版本为 v7.1.1 或更高版本。如需将 TiDB Cloud Dedicated 集群升级到 v7.1.1 或更高版本，请[联系 TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 -> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，变更订阅功能不可用。 +> - 若要将数据流式同步到云存储，请确保你的 TiDB 集群版本为 v7.1.1 或更高。如需将 TiDB Cloud Dedicated 集群升级到 v7.1.1 或更高版本，请[联系 TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 +> - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 和 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群，changefeed 功能不可用。 ## 限制 -- 每个 TiDB Cloud 集群最多可创建 100 个变更订阅。 -- 由于 TiDB Cloud 使用 TiCDC 建立变更订阅，因此具有与 [TiCDC 相同的限制](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)。 -- 如果待同步的表没有主键或非空唯一索引，在某些重试场景下，由于缺乏唯一约束，可能会导致下游插入重复数据。 +- 每个 TiDB Cloud 集群最多可创建 100 个 changefeed。 +- 由于 TiDB Cloud 使用 TiCDC 建立 changefeed，因此具有与 [TiCDC 相同的限制](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)。 +- 如果待同步的表没有主键或非空唯一索引，则在同步过程中由于缺乏唯一约束，在某些重试场景下可能会导致下游插入重复数据。 -## 第 1 步：配置目标端 +## 步骤 1. 配置目标端 -进入目标 TiDB 集群的集群总览页面。在左侧导航栏点击 **Data** > **Changefeed**，点击 **Create Changefeed**，并选择 **Amazon S3** 或 **GCS** 作为目标端。具体配置流程根据你选择的目标端有所不同。 +进入目标 TiDB 集群的集群总览页面。在左侧导航栏点击 **Data** > **Changefeed**，点击 **Create Changefeed**，并选择 **Amazon S3**、**GCS** 或 **Azure Blob Storage** 作为目标端。具体配置流程根据所选目标端不同而有所区别。
@@ -45,7 +45,7 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou ![Create a role](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-create-role.png) - 3. 输入角色的名称、描述、ID 以及角色的发布阶段。角色名称在创建后无法更改。 + 3. 输入角色的名称、描述、ID 及角色发布阶段。角色名称创建后不可更改。 4. 点击 **Add permissions**，为该角色添加以下权限，然后点击 **Add**。 - storage.buckets.get @@ -65,52 +65,92 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou 5. 填写以下信息以授予 bucket 访问权限，然后点击 **Save**。 - - 在 **New Principals** 字段中，粘贴你之前记录的目标 TiDB 集群的 **Service Account ID**。 - - 在 **Select a role** 下拉列表中，输入你刚刚创建的 IAM 角色名称，并从筛选结果中选择该名称。 + - 在 **New Principals** 字段中，粘贴之前记录的目标 TiDB 集群的 **Service Account ID**。 + - 在 **Select a role** 下拉列表中，输入刚刚创建的 IAM 角色名称，并从筛选结果中选择该名称。 > **注意：** > - > 若需移除 TiDB Cloud 的访问权限，只需删除你已授予的访问权限即可。 + > 若需移除 TiDB Cloud 的访问权限，只需移除你已授予的访问权限即可。 6. 在 **Bucket details** 页面，点击 **Objects** 标签页。 - - 获取 bucket 的 gsutil URI：点击复制按钮，并在前面加上 `gs://` 前缀。例如，若 bucket 名称为 `test-sink-gcs`，则 URI 为 `gs://test-sink-gcs/`。 + - 获取 bucket 的 gsutil URI：点击复制按钮，并在前面加上 `gs://` 前缀。例如，若 bucket 名为 `test-sink-gcs`，则 URI 为 `gs://test-sink-gcs/`。 ![Get bucket URI](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-uri01.png) - - 获取文件夹的 gsutil URI：进入文件夹，点击复制按钮，并在前面加上 `gs://` 前缀。例如，若 bucket 名称为 `test-sink-gcs`，文件夹名称为 `changefeed-xxx`，则 URI 为 `gs://test-sink-gcs/changefeed-xxx/`。 + - 获取文件夹的 gsutil URI：进入文件夹，点击复制按钮，并在前面加上 `gs://` 前缀。例如，若 bucket 名为 `test-sink-gcs`，文件夹名为 `changefeed-xxx`，则 URI 为 `gs://test-sink-gcs/changefeed-xxx/`。 ![Get bucket URI](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-uri02.png) 7. 回到 TiDB Cloud 控制台，在 Changefeed 的 **Configure Destination** 页面，填写 **bucket gsutil URI** 字段。 +
+
+ +对于 **Azure Blob Storage**，你需要先在 Azure 门户配置容器并获取 SAS token。请按照以下步骤操作： + +1. 在 [Azure 门户](https://portal.azure.com/) 创建一个用于存储 changefeed 数据的容器。 + + 1. 在左侧导航栏点击 **Storage Accounts**，然后选择你的存储账户。 + 2. 在存储账户导航菜单中，选择 **Data storage** > **Containers**，然后点击 **+ Container**。 + 3. 输入新容器的名称，设置匿名访问级别（推荐级别为 **Private**），然后点击 **Create**。 + +2. 获取目标容器的 URL。 + + 1. 在容器列表中，选择你的目标容器。 + 2. 点击容器的 **...**，然后选择 **Container properties**。 + 3. 保存 **URL** 值以备后用，例如 `https://.blob.core.windows.net/`。 + +3. 生成 SAS token。 + + 1. 在存储账户导航菜单中，选择 **Security + networking** > **Shared access signature**。 + 2. 在 **Allowed services** 区域，选择 **Blob**。 + 3. 在 **Allowed resource types** 区域，选择 **Container** 和 **Object**。 + 4. 在 **Allowed permissions** 区域，选择 **Read**、**Write**、**Delete**、**List** 和 **Create**。 + 5. 为 SAS token 指定一个足够长的有效期，以满足你的需求。 + + > **注意：** + > + > - changefeed 会持续写入事件，因此请确保 SAS token 的有效期足够长。出于安全考虑，建议每 6 到 12 个月更换一次 token。 + > - 生成的 SAS token 无法回收，因此请谨慎设置其有效期。 + > - 为保证持续可用性，请在 SAS token 过期前重新生成并更新 token。 + + 6. 点击 **Generate SAS and connection string**，然后保存 **SAS token**。 + + ![Generate a SAS token](/media/tidb-cloud/changefeed/sink-to-cloud-storage-azure-signature.png) + +4. 在 [TiDB Cloud 控制台](https://tidbcloud.com/) 的 Changefeed **Configure Destination** 页面，填写以下字段： + + - **Blob URL**：输入第 2 步获取的容器 URL，可选添加前缀。 + - **SAS Token**：输入第 3 步获取的 SAS token。 +
-点击 **Next**，建立 TiDB Cloud Dedicated 集群与 Amazon S3 或 GCS 的连接。TiDB Cloud 会自动测试并验证连接是否成功。 +点击 **Next**，建立 TiDB Cloud Dedicated 集群与 Amazon S3、GCS 或 Azure Blob Storage 的连接。TiDB Cloud 会自动测试并验证连接是否成功。 -- 如果连接成功，将进入下一步配置。 -- 如果连接失败，会显示连接错误，你需要处理该错误。错误解决后，点击 **Next** 重新尝试连接。 +- 若连接成功，将进入下一步配置。 +- 若连接失败，会显示连接错误，你需要处理该错误。错误解决后，点击 **Next** 重新尝试连接。 -## 第 2 步：配置同步 +## 步骤 2. 配置同步 -1. 自定义 **Table Filter**，筛选你希望同步的表。规则语法请参考 [table filter rules](https://docs.pingcap.com/tidb/stable/ticdc-filter#changefeed-log-filters)。 +1. 自定义 **Table Filter**，筛选你希望同步的表。规则语法详见 [table filter rules](https://docs.pingcap.com/tidb/stable/ticdc-filter#changefeed-log-filters)。 ![the table filter of changefeed](/media/tidb-cloud/changefeed/sink-to-s3-02-table-filter.jpg) - - **Case Sensitive**：你可以设置过滤规则中数据库和表名的匹配是否区分大小写。默认情况下，匹配不区分大小写。 - - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中的所有表，并在右侧框中仅显示符合规则的表。最多可添加 100 条过滤规则。 + - **Case Sensitive**：你可以设置过滤规则中数据库和表名的匹配是否大小写敏感。默认情况下，匹配为大小写不敏感。 + - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中所有表，并仅在右侧框中显示匹配规则的表。最多可添加 100 条过滤规则。 - **Tables with valid keys**：此列显示具有有效键（包括主键或唯一索引）的表。 - - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步过程中存在挑战，因为缺乏唯一标识符，处理下游重复事件时可能导致数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或者通过过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 + - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步时存在挑战，因为缺乏唯一标识符，在处理下游重复事件时可能导致数据不一致。为保证数据一致性，建议在启动同步前为这些表添加唯一键或主键，或通过过滤规则排除这些表。例如，可通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 2. 自定义 **Event Filter**，筛选你希望同步的事件。 - - **Tables matching**：你可以在此列设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个变更订阅最多可添加 10 条事件过滤规则。 - - **Event Filter**：你可以使用以下事件过滤器，从变更订阅中排除特定事件： + - **Tables matching**：你可以在此列设置事件过滤器将应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个 changefeed 最多可添加 10 条事件过滤规则。 + - **Event Filter**：你可以使用以下事件过滤器，从 changefeed 中排除特定事件： - **Ignore event**：排除指定类型的事件。 - - **Ignore SQL**：排除符合指定表达式的 DDL 事件。例如，`^drop` 排除以 `DROP` 开头的语句，`add column` 排除包含 `ADD COLUMN` 的语句。 + - **Ignore SQL**：排除匹配指定表达式的 DDL 事件。例如，`^drop` 排除以 `DROP` 开头的语句，`add column` 排除包含 `ADD COLUMN` 的语句。 - **Ignore insert value expression**：排除满足特定条件的 `INSERT` 语句。例如，`id >= 100` 排除 `id` 大于等于 100 的 `INSERT` 语句。 - - **Ignore update new value expression**：排除新值满足指定条件的 `UPDATE` 语句。例如，`gender = 'male'` 排除更新后 `gender` 为 `male` 的更新。 + - **Ignore update new value expression**：排除新值满足指定条件的 `UPDATE` 语句。例如，`gender = 'male'` 排除将 `gender` 修改为 `male` 的更新。 - **Ignore update old value expression**：排除旧值满足指定条件的 `UPDATE` 语句。例如，`age < 18` 排除旧值 `age` 小于 18 的更新。 - **Ignore delete value expression**：排除满足指定条件的 `DELETE` 语句。例如，`name = 'john'` 排除 `name` 为 `'john'` 的删除。 @@ -118,60 +158,60 @@ summary: 本文档介绍如何创建变更订阅（changefeed），将 TiDB Clou - 从现在开始同步 - 从指定的 [TSO](https://docs.pingcap.com/tidb/stable/glossary#tso) 开始同步 - - 从指定时间开始同步 + - 从指定时间点开始同步 4. 在 **Data Format** 区域，选择 **CSV** 或 **Canal-JSON** 格式。
- 配置 **CSV** 格式时，需填写以下字段： + 配置 **CSV** 格式时，填写以下字段： - - **Binary Encode Method**：二进制数据的编码方式。可选择 **base64**（默认）或 **hex**。如需与 AWS DMS 集成，建议选择 **hex**。 - - **Date Separator**：可按年、月、日对数据进行分片，或选择不分片。 + - **Binary Encode Method**：二进制数据的编码方法。可选择 **base64**（默认）或 **hex**。如需与 AWS DMS 集成，请选择 **hex**。 + - **Date Separator**：按年、月、日轮转数据，或选择不轮转。 - **Delimiter**：指定 CSV 文件中用于分隔值的字符。逗号（`,`）是最常用的分隔符。 - - **Quote**：指定用于包裹包含分隔符或特殊字符的值的字符。通常使用双引号（`"`）作为包裹字符。 - - **Null/Empty Values**：指定 CSV 文件中空值或 null 的表示方式。这对于数据的正确处理和解析非常重要。 + - **Quote**：指定用于包裹包含分隔符或特殊字符的值的字符。通常使用双引号（`"`）作为引用字符。 + - **Null/Empty Values**：指定在 CSV 文件中如何表示空值或空字符串。这对于正确处理和解析数据非常重要。 - **Include Commit Ts**：控制是否在 CSV 行中包含 [`commit-ts`](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-cloud-storage#replicate-change-data-to-storage-services)。
- Canal-JSON 是一种纯文本 JSON 格式。配置时需填写以下字段： + Canal-JSON 是一种纯 JSON 文本格式。配置时填写以下字段： - - **Date Separator**：可按年、月、日对数据进行分片，或选择不分片。 - - **Enable TiDB Extension**：启用后，TiCDC 会发送 [WATERMARK 事件](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#watermark-event)，并在 Canal-JSON 消息中添加 [TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。 + - **Date Separator**：按年、月、日轮转数据，或选择不轮转。 + - **Enable TiDB Extension**：启用后，TiCDC 会发送 [WATERMARK 事件](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#watermark-event) 并在 Canal-JSON 消息中添加 [TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。
5. 在 **Flush Parameters** 区域，你可以配置以下两项： - - **Flush Interval**：默认 60 秒，可在 2 秒到 10 分钟范围内调整； - - **File Size**：默认 64 MB，可在 1 MB 到 512 MB 范围内调整。 + - **Flush Interval**：默认 60 秒，可在 2 秒至 10 分钟范围内调整； + - **File Size**：默认 64 MB，可在 1 MB 至 512 MB 范围内调整。 ![Flush Parameters](/media/tidb-cloud/changefeed/sink-to-cloud-storage-flush-parameters.jpg) > **注意：** > - > 这两个参数会影响每个数据库表在云存储中生成的对象数量。如果表数量较多，使用相同配置会增加生成对象的数量，从而提升云存储 API 的调用成本。因此，建议根据你的恢复点目标（RPO）和成本需求合理配置这些参数。 + > 这两个参数会影响每个数据库表在云存储中生成的对象数量。如果表数量较多，使用相同配置会增加生成对象的数量，并提升调用云存储 API 的成本。因此，建议根据你的恢复点目标（RPO）和成本需求合理配置这些参数。 -6. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件拆分为单独的 `DELETE` 和 `INSERT` 事件，或保留为原始的 `UPDATE` 事件。更多信息请参见 [Split primary or unique key UPDATE events for non-MySQL sinks](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 +6. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件切分为单独的 `DELETE` 和 `INSERT` 事件，或保持为原始 `UPDATE` 事件。详细信息参见 [Split primary or unique key UPDATE events for non-MySQL sinks](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 -## 第 3 步：配置规范 +## 步骤 3. 配置规范 -点击 **Next**，进入变更订阅规范配置。 +点击 **Next**，配置 changefeed 规范。 -1. 在 **Changefeed Specification** 区域，指定变更订阅使用的 Replication Capacity Units（RCU）数量。 -2. 在 **Changefeed Name** 区域，为变更订阅指定一个名称。 +1. 在 **Changefeed Specification** 区域，指定 changefeed 使用的 Replication Capacity Units (RCUs) 数量。 +2. 在 **Changefeed Name** 区域，指定 changefeed 的名称。 -## 第 4 步：检查配置并启动同步 +## 步骤 4. 审核配置并启动同步 -点击 **Next**，检查变更订阅的配置信息。 +点击 **Next**，审核 changefeed 配置。 -- 如果你已确认所有配置无误，点击 **Create** 以创建变更订阅。 -- 如果需要修改配置，点击 **Previous** 返回并进行相应调整。 +- 如果你已确认所有配置无误，点击 **Create** 以创建 changefeed。 +- 如果需要修改配置，点击 **Previous** 返回并进行相应更改。 -同步任务会很快启动，你会看到同步状态从 **Creating** 变为 **Running**。 +sink 很快会启动，你会看到 sink 状态从 **Creating** 变为 **Running**。 -点击变更订阅名称可进入详情页面。在该页面，你可以查看更多关于变更订阅的信息，包括检查点状态、同步延迟及其他相关指标。 \ No newline at end of file +点击 changefeed 名称可进入详情页面。在该页面，你可以查看更多关于 changefeed 的信息，包括 checkpoint 状态、同步延时及其他相关统计/指标（信息）。 \ No newline at end of file diff --git a/tidb-cloud/dev-guide-bi-looker-studio.md b/tidb-cloud/dev-guide-bi-looker-studio.md deleted file mode 100644 index cedded4507766..0000000000000 --- a/tidb-cloud/dev-guide-bi-looker-studio.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: 使用 Looker Studio 连接 TiDB Cloud -summary: 了解如何使用 Looker Studio 连接 TiDB Cloud。 ---- - -# 使用 Looker Studio 连接 TiDB Cloud - -TiDB 是一个兼容 MySQL 的数据库，TiDB Cloud 是一款完全托管的数据库即服务（DBaaS），可将 TiDB 部署到你的云环境中，[Looker Studio](https://lookerstudio.google.com/) 是一款免费的基于 Web 的 BI 工具，可以可视化来自多种数据源的数据。 - -本教程以 TiDB Cloud Starter 集群为例，演示如何使用 Looker Studio 连接 TiDB Cloud。 - -> **注意：** -> -> - 除了 TiDB Cloud Starter 集群外，本文档中的步骤同样适用于 TiDB Cloud Essential 集群。 -> - 本教程的大部分步骤也适用于 TiDB Cloud Dedicated。但对于 TiDB Cloud Dedicated，你需要注意以下事项： -> - 按照 [从文件导入数据到 TiDB Cloud](/tidb-cloud/tidb-cloud-migration-overview.md#import-data-from-files-to-tidb-cloud) 导入你的数据集。 -> - 按照 [连接到 TiDB Cloud Dedicated](/tidb-cloud/connect-via-standard-connection.md) 获取你的集群连接信息。连接 TiDB Cloud Dedicated 时，你需要允许来自 `142.251.74.0/23` 的访问。关于 Looker Studio 的连接详情，请参阅 [Looker Studio 文档](https://support.google.com/looker-studio/answer/7088031#zippy=%2Cin-this-article)。 - -## 前置条件 - -完成本教程，你需要： - -- 一个 Google 账号 -- 一个 TiDB Cloud Starter 集群 - -**如果你还没有 TiDB Cloud Starter 集群，可以按如下方式创建：** - -- [创建 TiDB Cloud Starter 集群](/develop/dev-guide-build-cluster-in-cloud.md#step-1-create-a-tidb-cloud-cluster) - -## 步骤 1. 导入数据集 - -你可以导入 TiDB Cloud Starter 交互式教程中提供的 S&P 500 数据集。 - -1. 进入 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击右下角的 **?**。此时会弹出 **Help** 对话框。 - -2. 在对话框中，点击 **Interactive Tutorials**，然后点击 **S&P 500 Analysis**。 - -3. 选择你的 TiDB Cloud Starter 集群，然后点击 **Import Dataset**，将 S&P 500 数据集导入到你的集群中。 - -4. 当导入状态变为 **IMPORTED** 后，点击 **Exit Tutorial** 关闭该对话框。 - -如果在导入过程中遇到问题，你可以按如下方式取消该导入任务： - -1. 在 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击你的 TiDB Cloud Starter 集群名称，进入其概览页面。 -2. 在左侧导航栏，点击 **Data** > **Import**。 -3. 找到名为 **sp500-insight** 的导入任务，在 **Action** 列点击 **...**，然后点击 **Cancel**。 - -## 步骤 2. 获取集群连接信息 - -1. 进入 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，点击目标集群名称，进入其概览页面。 - -2. 点击右上角的 **Connect**，弹出连接对话框。 - -3. 在连接对话框中，将 **Connect With** 设置为 `General`，然后点击 **Generate Password** 生成一个随机密码。 - - > **提示：** - > - > 如果你之前已经创建过密码，请使用原密码，或点击 **Reset Password** 生成新密码。 - -4. 下载 [CA cert](https://letsencrypt.org/certs/isrgrootx1.pem)。 - - > **提示：** - > - > TiDB Cloud Starter 要求客户端与集群之间建立安全的 TLS 连接，因此你需要在 Looker Studio 的连接设置中使用该 CA 证书。 - -## 步骤 3. 使用 Looker Studio 连接 TiDB 集群 - -1. 登录 [Looker Studio](https://lookerstudio.google.com/)，在左侧导航栏点击 **Create** > **Report**。 - -2. 在弹出页面中，搜索并选择 **MySQL** 连接器，然后点击 **AUTHORIZE**。 - -3. 在 **BASIC** 设置面板中，配置连接参数。 - - - **Host Name or IP**：输入 TiDB Cloud Starter 连接对话框中的 `HOST` 参数。 - - **Port(Optional)**：输入 TiDB Cloud Starter 连接对话框中的 `PORT` 参数。 - - **Database**：输入你要连接的数据库。本教程中输入 `sp500insight`。 - - **Username**：输入 TiDB Cloud Starter 连接对话框中的 `USERNAME` 参数。 - - **Password**：输入 TiDB Cloud Starter 连接对话框中的 `PASSWORD` 参数。 - - **Enable SSL**：勾选此项，然后点击 **MySQL SSL Client Configuration Files** 右侧的上传图标，上传在 [步骤 2](#step-2-get-the-connection-information-for-your-cluster) 下载的 CA 文件。 - - ![Looker Studio: 配置 TiDB Cloud Starter 连接设置](/media/tidb-cloud/looker-studio-configure-connection.png) - -4. 点击 **AUTHENTICATE**。 - -认证成功后，你可以看到数据库中的表。 - -## 步骤 4. 创建一个简单图表 - -现在，你可以将 TiDB 集群作为数据源，创建一个简单的数据图表。 - -1. 在右侧面板点击 **CUSTOM QUERY**。 - - ![Looker Studio: 自定义查询](/media/tidb-cloud/looker-studio-custom-query.png) - -2. 将以下代码复制到 **Enter Custom Query** 区域，然后点击右下角的 **Add**。 - - ```sql - SELECT sector, - COUNT(*) AS companies, - ROW_NUMBER() OVER (ORDER BY COUNT(*) DESC ) AS companies_ranking, - SUM(market_cap) AS total_market_cap, - ROW_NUMBER() OVER (ORDER BY SUM(market_cap) DESC ) AS total_market_cap_ranking, - SUM(revenue_growth * weight) / SUM(weight) AS avg_revenue_growth, - ROW_NUMBER() OVER (ORDER BY SUM(revenue_growth * weight) / SUM(weight) DESC ) AS avg_revenue_growth_ranking - FROM companies - LEFT JOIN index_compositions ic ON companies.stock_symbol = ic.stock_symbol - GROUP BY sector - ORDER BY 5 ASC; - ``` - - 如果弹出 **You are about to add data to this report** 对话框，点击 **ADD TO REPORT**。随后，报表中会显示一个表格。 - -3. 在报表工具栏点击 **Add a chart**，然后在 `Line` 分类下选择 `Combo chart`。 - -4. 在右侧 **Chart** 设置面板，配置以下参数： - - - 在 **SETUP** 标签页： - - **Dimension**：`sector` - - **Metric**：`companies` 和 `total_market_cap` - - 在 **STYLE** 标签页： - - Series #1：选择 `Line` 选项并设置为 `Right` 轴。 - - Series #2：选择 `Bars` 选项并设置为 `Left` 轴。 - - 其他字段保持默认。 - -此时，你可以看到如下所示的组合图表： - -![Looker Studio: 一个简单的组合图表](/media/tidb-cloud/looker-studio-simple-chart.png) - -## 后续步骤 - -- 通过 [Looker Studio 帮助中心](https://support.google.com/looker-studio) 了解更多 Looker Studio 的用法。 -- 通过 [开发者指南](/develop/dev-guide-overview.md) 各章节，学习 TiDB 应用开发最佳实践，例如 [插入数据](/develop/dev-guide-insert-data.md)、[更新数据](/develop/dev-guide-update-data.md)、[删除数据](/develop/dev-guide-delete-data.md)、[单表读取](/develop/dev-guide-get-data-from-single-table.md)、[事务](/develop/dev-guide-transaction-overview.md) 和 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md)。 -- 通过专业的 [TiDB 开发者课程](https://www.pingcap.com/education/)，考试通过后获得 [TiDB 认证](https://www.pingcap.com/education/certification/)。 - -## 需要帮助？ - -欢迎在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](https://tidb.support.pingcap.com/)。 \ No newline at end of file diff --git a/tidb-cloud/essential-changefeed-overview.md b/tidb-cloud/essential-changefeed-overview.md index 1a4a79b803464..1ee69ad3877fc 100644 --- a/tidb-cloud/essential-changefeed-overview.md +++ b/tidb-cloud/essential-changefeed-overview.md @@ -1,9 +1,9 @@ --- -title: Changefeed（Beta） +title: Changefeed (Beta) summary: TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数据服务。 --- -# Changefeed（Beta） +# Changefeed (Beta) TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数据服务。目前，TiDB Cloud 支持将数据流式传输到 Apache Kafka 和 MySQL。 @@ -12,16 +12,21 @@ TiDB Cloud changefeed 帮助你将数据从 TiDB Cloud 流式传输到其他数 > - 目前，TiDB Cloud 每个 TiDB Cloud Essential 集群最多只允许创建 10 个 changefeed。 > - 对于 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群，changefeed 功能不可用。 +## 限制 + +- changefeed 不支持在单个 `RENAME TABLE` 语句中重命名多个表的 DDL 语句，例如 `RENAME TABLE t1 TO t3, t2 TO t4`。执行该语句会永久中断 changefeed 的数据同步。 +- changefeed 的吞吐约为 20 MiB/s。如果你的增量数据量超过此限制，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取帮助。 + ## 支持的区域 changefeed 功能目前在以下区域可用： | 云服务商 | 支持的区域 | | --- | --- | -| AWS | | +| AWS | | | 阿里云 | | -未来将支持更多区域。如果你需要在特定区域立即获得支持，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 +未来将支持更多区域。如果你需要在特定区域立即支持，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 ## 查看 Changefeed 页面 @@ -33,9 +38,9 @@ changefeed 功能目前在以下区域可用： > > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 -2. 点击目标集群的名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Changefeed**。此时会显示 changefeed 页面。 +2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Changefeed**。此时会显示 changefeed 页面。 -在 **Changefeed** 页面，你可以创建 changefeed，查看已有 changefeed 列表，并对已有 changefeed 进行操作（如暂停、恢复、编辑和删除 changefeed）。 +在 **Changefeed** 页面，你可以创建 changefeed，查看已有 changefeed 列表，并对已有 changefeed 进行操作（如暂停、恢复、修改/编辑和删除 changefeed）。 ## 创建 changefeed @@ -97,27 +102,27 @@ ticloud serverless changefeed resume -c --changefeed-id -## 编辑 changefeed +## 修改/编辑 changefeed > **注意：** > -> TiDB Cloud 目前仅允许在 changefeed 处于暂停状态时进行编辑。 +> TiDB Cloud 目前仅允许在 changefeed 处于暂停状态时进行修改/编辑。 -你可以通过 TiDB Cloud 控制台或 TiDB Cloud CLI 编辑 changefeed。 +你可以通过 TiDB Cloud 控制台或 TiDB Cloud CLI 修改/编辑 changefeed。
1. 进入目标 TiDB 集群的 [**Changefeed**](#view-the-changefeed-page) 页面。 2. 找到你想要暂停的 changefeed，在 **Action** 列点击 **...** > **Pause**。 -3. 当 changefeed 状态变为 `Paused` 后，点击 **...** > **Edit** 以编辑对应的 changefeed。 +3. 当 changefeed 状态变为 `Paused` 后，点击 **...** > **Edit** 以修改/编辑对应的 changefeed。 - TiDB Cloud 默认会填充 changefeed 配置。你可以修改以下配置项： + TiDB Cloud 默认填充 changefeed 配置。你可以修改以下配置： - Apache Kafka sink：除 **Destination**、**Connection** 和 **Start Position** 外的所有配置 - MySQL sink：除 **Destination**、**Connection** 和 **Start Position** 外的所有配置 -4. 编辑配置后，点击 **...** > **Resume** 以恢复对应的 changefeed。 +4. 修改配置后，点击 **...** > **Resume** 以恢复对应的 changefeed。
@@ -142,8 +147,8 @@ ticloud serverless changefeed edit --cluster-id --changefeed-id **Duplicate**。 -3. TiDB Cloud 会自动用原有设置填充新的 changefeed 配置。你可以根据需要查看并修改配置。 -4. 确认配置后，点击 **Submit** 以创建并启动新的 changefeed。 +3. TiDB Cloud 会自动用原有设置填充新 changefeed 的配置。你可以根据需要检查并修改配置。 +4. 确认配置后，点击 **Submit** 创建并启动新的 changefeed。 ## 删除 changefeed @@ -168,11 +173,11 @@ ticloud serverless changefeed delete --cluster-id --changefeed-id < -## Changefeed 计费 +## changefeed 计费 changefeed 在 beta 阶段免费。 -## Changefeed 状态 +## changefeed 状态 在运行过程中，changefeed 可能因错误而失败，或被手动暂停或恢复。这些操作会导致 changefeed 状态发生变化。 @@ -182,5 +187,5 @@ changefeed 在 beta 阶段免费。 - `CREATE_FAILED`：changefeed 创建失败。你需要删除该 changefeed 并重新创建。 - `RUNNING`：changefeed 正常运行，checkpoint-ts 正常推进。 - `PAUSED`：changefeed 已暂停。 -- `WARNING`：changefeed 返回警告。由于某些可恢复的错误，changefeed 无法继续。处于该状态的 changefeed 会持续尝试恢复，直到状态变为 `RUNNING`。该状态下的 changefeed 会阻塞 [GC 操作](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)。 +- `WARNING`：changefeed 返回警告。由于某些可恢复错误，changefeed 无法继续。处于该状态的 changefeed 会持续尝试恢复，直到状态变为 `RUNNING`。该状态下的 changefeed 会阻塞 [GC 操作](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)。 - `RUNNING_FAILED`：changefeed 运行失败。由于某些错误，changefeed 无法恢复且无法自动修复。如果在增量数据的垃圾回收（GC）之前解决了问题，你可以手动恢复失败的 changefeed。增量数据的默认生存时间（TTL）为 24 小时，即 changefeed 中断后 24 小时内 GC 机制不会删除任何数据。 \ No newline at end of file diff --git a/tidb-cloud/tidb-cloud-release-notes.md b/tidb-cloud/tidb-cloud-release-notes.md index 6621184985411..652f81727d14f 100644 --- a/tidb-cloud/tidb-cloud-release-notes.md +++ b/tidb-cloud/tidb-cloud-release-notes.md @@ -8,13 +8,25 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] 本页面列出了 [TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 在 2026 年的发布说明。 +## 2026 年 2 月 3 日 + +**通用变更** + +- **TiDB Cloud Dedicated** + + - 支持将变更数据下沉至 Azure Blob Storage。 + + [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 现在支持将变更数据直接下沉到 Azure Blob Storage。该功能使基于 Azure 的用户能够高效归档变更数据，以便下游分析和长期保存。同时，通过省去中间消息队列，降低了成本，并且保持了与现有 Amazon S3 和 Google Cloud Storage (GCS) 下沉的格式兼容性。 + + 详细信息参见 [下沉到云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 + ## 2026 年 1 月 27 日 **通用变更** - **TiDB Cloud Dedicated** - - 支持将 Flashduty 和 PagerDuty 作为报警订阅渠道。 + - 支持 Flashduty 和 PagerDuty 作为告警订阅渠道。 这些集成旨在简化你的事件管理流程，并提升运维可靠性。 @@ -26,44 +38,44 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - **TiDB Cloud Starter** - - 在 [慢查询](/tidb-cloud/tune-performance.md#slow-query) 视图和 [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md) 表中显示真实 client IP 地址（测试版）。 + - 在 [慢查询](/tidb-cloud/tune-performance.md#slow-query) 视图和 [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md) 表中显示真实客户端 IP 地址（测试版）。 - TiDB Cloud 现已支持 client IP 透传，使慢查询视图和 `INFORMATION_SCHEMA.PROCESSLIST` 表能够显示真实的 client IP 地址，而不是负载均衡器（LB）IP。该功能有助于更准确地识别数据库 request 的真实来源，便于排查和分析。 + TiDB Cloud 现已支持客户端 IP 透传，使慢查询视图和 `INFORMATION_SCHEMA.PROCESSLIST` 表能够显示真实的客户端 IP 地址，而非负载均衡器（LB）IP。该功能有助于更准确地识别数据库请求的真实来源，便于排查和分析。 目前，该功能为测试版，仅在 AWS 区域 `Frankfurt (eu-central-1)` 提供。 - **TiDB Cloud Essential** - - 支持数据 migration（测试版）。 + - 支持数据迁移（测试版）。 - 你现在可以在 [TiDB Cloud 控制台](https://tidbcloud.com) 使用数据 migration 功能，将任意 MySQL-compatible 数据库的数据无缝迁移到你的 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) cluster。 + 你现在可以在 [TiDB Cloud 控制台](https://tidbcloud.com) 使用数据迁移功能，将任意 MySQL 兼容数据库的数据无缝迁移到你的 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群。 - - 支持的源数据库包括多种 MySQL-compatible 系统，如自建 MySQL、Amazon RDS、阿里云 RDS 以及 PolarDB。 - - 数据 migration 支持的连接 method 包括公网连接和 PrivateLink，兼顾易用性与企业级安全： + - 支持的源数据库包括多种 MySQL 兼容系统，如自建 MySQL、Amazon RDS、阿里云 RDS 以及 PolarDB。 + - 支持的数据迁移连接方法包括公网连接和 PrivateLink，兼顾易用性和企业级安全性： - - **公网连接**：通过安全加密通道，快速通过互联网连接到你的源数据库。 - - **PrivateLink**：在你的源 VPC 与 TiDB Cloud 之间建立安全私有连接，绕过公网，确保数据隐私并降低网络 latency。 + - **公网连接**：通过安全加密通道，快速连接到你的源数据库。 + - **PrivateLink**：在你的源 VPC 与 TiDB Cloud 之间建立安全私有连接，绕过公网，确保数据隐私并降低网络延时。 - 目前，数据 migration 功能仅支持 logic 模式。 + 目前，数据迁移功能仅支持逻辑模式。 - 详细信息参见 [使用数据 migration 迁移现有及增量数据](/tidb-cloud/migrate-from-mysql-using-data-migration.md) 和 [使用数据 migration 迁移增量数据](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)。 + 详细信息参见 [使用数据迁移迁移现有及增量数据](/tidb-cloud/migrate-from-mysql-using-data-migration.md) 和 [使用数据迁移迁移增量数据](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)。 - - 在 [慢查询](/tidb-cloud/tune-performance.md#slow-query) 视图、[数据库审计日志](/tidb-cloud/essential-database-audit-logging.md) 和 [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md) 表中显示真实 client IP 地址（测试版） + - 在 [慢查询](/tidb-cloud/tune-performance.md#slow-query) 视图、[数据库审计日志](/tidb-cloud/essential-database-audit-logging.md) 和 [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md) 表中显示真实客户端 IP 地址（测试版） - TiDB Cloud 现已支持 client IP 透传，使慢查询视图、数据库审计日志和 `INFORMATION_SCHEMA.PROCESSLIST` 表能够显示真实的 client IP 地址，而不是负载均衡器（LB）IP。该功能有助于更准确地识别数据库 request 的真实来源，便于排查和分析。 + TiDB Cloud 现已支持客户端 IP 透传，使慢查询视图、数据库审计日志和 `INFORMATION_SCHEMA.PROCESSLIST` 表能够显示真实的客户端 IP 地址，而非负载均衡器（LB）IP。该功能有助于更准确地识别数据库请求的真实来源，便于排查和分析。 目前，该功能为测试版，仅在 AWS 区域 `Frankfurt (eu-central-1)` 提供。 **控制台变更** -- 通过支持计划感知的支持选项，提升支持体验。 +- 提升支持体验，提供基于订阅计划的支持选项。 - [TiDB Cloud 控制台](https://tidbcloud.com/) 现已提供计划感知的支持选项，以提升所有订阅计划下的支持体验。此次更新包括： + [TiDB Cloud 控制台](https://tidbcloud.com/) 现已提供基于订阅计划的支持选项，提升所有订阅计划下的支持体验。此次更新包括： - - **计划感知的支持重定向**：在 cluster 概览页面，点击 **Get Support** 按钮（位于 **Actions** 列）会根据你的订阅计划将你引导至最相关的资源。Basic 计划用户会被引导至 **Support Plan** 面板，付费计划用户则会被引导至 **Support Portal**。 - - **优化的帮助中心菜单**：将帮助菜单项重命名为 **Support Options** 和 **Support Tickets**，以更好地反映可用服务。新增提示，明确技术支持工单仅对付费计划开放。 - - **清晰的社区支持 access**：在 **Support Plan** 选项中，Slack 和 Discord 被明确标识为 Basic 计划用户的主要技术支持渠道。以下文档已优化，进一步明确支持渠道政策及社区 access：[TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)、[Connected Care Overview](/tidb-cloud/connected-care-overview.md) 和 [Connected Care Details](/tidb-cloud/connected-care-detail.md)。 - - **以操作为导向的 Support Plan UI**：重新设计 **Support Plan** 窗口，优先展示你当前订阅计划下可用的支持选项，而非通用计划对比。此更改有助于你快速识别基于当前计划的支持方式。 + - **基于计划的支持跳转**：在集群总览页面，点击 **Get Support** 按钮后，会根据你的订阅计划跳转到最相关的资源。Basic 计划用户会被引导至 **Support Plan** 面板，付费计划用户则跳转至 **Support Portal**。 + - **优化的帮助中心菜单**：将帮助菜单项重命名为 **Support Options** 和 **Support Tickets**，更准确地反映可用服务。新增提示，说明技术支持工单仅对付费计划开放。 + - **清晰的社区支持入口**：在 **Support Plan** 选项中，Slack 和 Discord 被明确标识为 Basic 计划用户的主要技术支持渠道。以下文档已优化，进一步明确支持渠道政策及社区访问方式：[TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)、[Connected Care Overview](/tidb-cloud/connected-care-overview.md) 和 [Connected Care Details](/tidb-cloud/connected-care-detail.md)。 + - **以操作为导向的 Support Plan 界面**：重新设计 **Support Plan** 窗口，优先展示你当前订阅计划下可用的支持选项，而非通用的计划对比。此变更有助于你快速识别基于当前计划的支持方式。 详细信息参见 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 @@ -73,4 +85,4 @@ aliases: ['/tidbcloud/supported-tidb-versions','/tidbcloud/release-notes'] - **TiDB Cloud Dedicated** - - 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) cluster 的默认 TiDB 版本由 [v8.5.4](https://docs.pingcap.com/tidb/v8.5/release-8.5.4/) 升级至 [v8.5.5](https://docs.pingcap.com/tidb/v8.5/release-8.5.5/)。 \ No newline at end of file + - 新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本由 [v8.5.4](https://docs.pingcap.com/tidb/v8.5/release-8.5.4/) 升级至 [v8.5.5](https://docs.pingcap.com/tidb/v8.5/release-8.5.5/)。 \ No newline at end of file diff --git a/tidb-cloud/tidb-x-architecture.md b/tidb-cloud/tidb-x-architecture.md new file mode 100644 index 0000000000000..7681a620143dc --- /dev/null +++ b/tidb-cloud/tidb-x-architecture.md @@ -0,0 +1,159 @@ +--- +title: TiDB X 架构 +summary: 了解基于 shared-storage（共享存储）的云原生 TiDB X 架构如何实现弹性扩展、可预测性能以及优化的总体拥有成本。 +--- + +# TiDB X 架构 + +TiDB X 是一种全新的分布式 SQL 架构，其在设计上将云原生对象存储作为 TiDB 的核心存储基础。目前该架构已在 TiDB Cloud Starter 和 EssentialStarter、Essential 和 Premium 提供支持，能够为 AI 时代的工作负载带来弹性扩展、可预测性能以及优化的总体拥有成本（TCO）。 + +TiDB X 代表了从 [经典 TiDB](/tidb-architecture.md) 的 shared-nothing（无共享）架构向云原生 shared-storage（共享存储）架构的根本性演进。通过将对象存储作为共享的持久化存储层，TiDB X 实现了计算工作负载的分离，从而将在线事务处理工作负载与资源密集型后台任务相隔离。 + +本文将介绍 TiDB X 架构，阐述 TiDB X 的设计动机，并说明与经典 TiDB 架构相比的关键创新点。 + +## 经典 TiDB 的局限性 + +本节将分析经典 TiDB 的架构及其局限性，这些局限性推动了 TiDB X 的诞生。 + +### 经典 TiDB 的优势 + +经典 TiDB 的 shared-nothing（无共享）架构解决了传统单体数据库的诸多限制。通过将计算与存储解耦，并利用 Raft 一致性算法，经典 TiDB 为分布式 SQL 工作负载提供了所需的高可用性和可扩展性。 + +经典 TiDB 架构具备以下基础能力： + +- **水平扩展**：支持读写性能的线性扩展。集群能够扩展到每秒处理数百万次查询（QPS），并管理超过 1 PiB 的数据和数千万张表。 +- **HTAP (Hybrid Transactional and Analytical Processing)**：统一事务处理与分析处理工作负载。通过将复杂的聚合和连接运算下推到 TiFlash（列式存储引擎），在无需复杂 ETL 管道的情况下即可对最新事务数据进行实时分析。 +- **非阻塞的模式变更**：采用完全在线的 DDL 实现方式。模式变更不会阻塞读写操作，使数据模型能够在几乎不影响应用延时或可用性的情况下持续演进。 +- **高可用**：支持无缝的集群升级和扩缩容操作，确保在维护或资源调整期间关键服务始终可用。 +- **多云支持**：作为开源解决方案，支持 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和 Alibaba CloudAmazon Web Services (AWS)、Google Cloud 和 Microsoft Azure，提供云平台中立性，避免厂商锁定。 + +### 经典 TiDB 面临的挑战 + +尽管经典 TiDB 的 shared-nothing（无共享）架构具备较高的可靠性，但由于在本地节点上将存储与计算紧密耦合，在超大规模环境下仍会暴露出一些限制。随着数据规模的增长以及云原生需求的演进，若干结构性挑战逐渐显现。 + +- **扩展性限制** + + - 数据迁移开销：在经典 TiDB 中，扩容（增加节点）或缩容（移除节点）都需要在节点之间进行 SST 文件的物理迁移。对于大规模数据集，这一过程耗时较长，并且在迁移过程中会消耗大量 CPU 和 I/O 资源，从而可能影响在线业务性能。 + + - 存储引擎瓶颈：经典 TiDB 底层使用的 RocksDB 存储引擎采用单一 LSM tree，并通过全局 mutex 互斥锁进行保护。这种设计会带来扩展性上限，当数据量很大时（例如单个 TiKV 节点超过 6 TiB 数据或超过 30 万个 SST 文件），系统难以充分利用硬件资源。 + +- **稳定性与性能干扰** + + - 资源争用：大量写入流量会触发本地 compaction 作业以合并 SST 文件。在经典 TiDB 中，由于 compaction 与在线流量运行在同一 TiKV 节点上，它们会竞争相同的 CPU 和 I/O 资源，从而可能影响在线应用。 + + - 缺乏物理隔离：逻辑 Region 与物理 SST 文件之间没有物理隔离。诸如 Region 迁移（负载均衡）等操作会引发 compaction 开销，并直接与用户查询竞争资源，可能导致性能抖动。 + + - 写入限流：在高写入压力下，如果后台 compaction 无法跟上前台写入速度，经典 TiDB 会触发流量控制机制以保护存储引擎。这会导致写吞吐受限，并使应用延时出现波动。 + +- **资源利用率与成本问题** + + - 过度预配：为了在高峰流量和后台维护任务同时存在时保持稳定性和性能，用户通常需要根据“高水位”需求进行硬件过度预配。 + + - 扩展不灵活：由于计算与存储耦合，用户可能不得不增加昂贵的高配置计算节点来获取更多存储容量，即使 CPU 利用率仍然较低。 + +### TiDB X 的设计动机 + +TiDB X 的推出源于将数据与物理计算资源解耦的需求。通过从 shared-nothing（无共享）架构转向 shared-storage（共享存储）架构，TiDB X 解决了耦合节点带来的物理限制，并实现以下技术目标： + +- **加速扩展**：通过消除物理数据迁移需求，将扩缩容性能提升最高达 10 倍。 +- **任务隔离**：确保后台维护任务（例如 compaction）与在线事务流量之间实现零干扰。 +- **资源弹性**：实现真正的“按需付费”模型，使计算资源可以独立于存储容量进行弹性扩展。 + +有关该架构演进的更多背景信息，请参阅博客文章 [The Making of TiDB X: Origins, Architecture, and What’s to Come](https://www.pingcap.com/blog/tidbx-origins-architecture/)。 + +## TiDB X 架构概览 + +TiDB X 是经典 TiDB 分布式设计的云原生演进版本。它继承了经典 TiDB 的以下架构优势： + +- **无状态 SQL 层**：SQL 层（TiDB server）是无状态的，负责查询解析、优化和执行，但不存储持久化数据。 +- **网关与连接管理**：TiProxy（或负载均衡器）维护持久的客户端连接并无缝路由 SQL 流量。TiProxy 最初用于支持在线升级，现在已成为天然的网关组件。 +- **基于 [Region](/tidb-cloud/tidb-cloud-glossary.md#region) 的动态分片**：TiKV 使用基于范围的分片单元 Region（默认 256 MiB）。数据被拆分为数百万个 Region，系统会自动管理 Region 的放置、迁移和负载均衡。 + +TiDB X 在这些基础之上，将本地 shared-nothing（无共享）存储替换为 **云原生 shared-storage（共享存储）对象存储**。这一转变实现了“[计算与计算分离](#separation-of-compute-and-compute)”模型，将资源密集型任务卸载到弹性资源池，从而实现即时扩展和可预测性能。 + +TiDB X 的整体架构如下图所示： + +![TiDB X Architecture](/media/tidb-x/tidb-x-architecture.png) + +### 对象存储支持 + +TiDB X 使用对象存储（例如 Amazon S3）作为所有数据的唯一来源。与经典架构中将数据存储在本地磁盘不同，TiDB X 将所有持久化数据存储在 **共享对象存储层** 中，而上层的 **共享缓存层**（行存引擎和列存引擎）则作为高性能缓存以保证低延时。 + +由于所有数据已存储在对象存储中，备份操作只需依赖存储在 S3 中的增量 Raft 日志和元信息，因此无论数据量多大，备份都可以在数秒内完成。在扩容场景中，新加入的 TiKV 节点无需从现有节点复制大量数据，而是直接连接对象存储并按需加载所需数据，从而显著加快扩容速度。 + +### 自动扩缩容机制 + +TiDB X 架构为弹性扩展而设计，并通过负载均衡器以及 **隔离 SQL 层** 的无状态特性实现自动扩缩容。共享缓存层可以根据 CPU 使用率或磁盘容量进行弹性扩展，系统能够在数秒内自动增加或减少计算 Pod，以适应实时工作负载变化。 + +这种技术弹性使按量计费的付费模式成为可能。用户无需再为峰值流量预配资源，而是可以在流量高峰时自动扩容，在空闲时自动缩容，从而降低成本。 + +### 微服务化与工作负载隔离 + +TiDB X 通过精细化的职责分离来确保不同类型的工作负载互不干扰。**隔离 SQL 层** 由多个独立的计算节点组组成，可支持工作负载隔离或多租户场景，使不同应用在共享数据的同时使用各自专用的计算资源。 + +**共享服务层** 将复杂的数据库操作拆分为独立的微服务，包括 compaction、统计信息收集和 DDL 执行等。通过将索引创建、大规模数据导入等资源密集型后台操作卸载到该层，TiDB X 能够避免这些操作与处理在线流量的计算节点竞争 CPU 和内存资源。这一设计为关键应用提供了更可预测的性能，并允许网关、SQL 计算层、缓存层和后台服务层根据各自需求独立扩展。 + +## TiDB X 的关键创新 + +下图对经典 TiDB 与 TiDB X 架构进行了并排对比，展示了从 **shared-nothing（无共享）** 设计到 **shared-storage（共享存储）** 设计的转变，以及计算工作负载分离的引入。 + +![Classic TiDB vs TiDB X architecture](/media/tidb-x/tidb-classic-vs-tidb-x-1.png) + +- **引擎演进**：在经典 TiDB 中，Raft engine 负责 multi-raft log 管理，RocksDB 负责本地磁盘上的物理数据存储。在 TiDB X 中，这些组件被全新的 **RF engine（Raft 引擎）** 和重新设计的 **KV engine** 所取代。新的 KV engine 是一种 LSM tree 存储引擎，用于替代 RocksDB。两种新引擎都针对高性能和对象存储的无缝集成进行了专门优化。 + +- **计算工作负载分离**：图中的虚线表示与对象存储层之间的后台读写操作。在 TiDB X 中，RF/KV engine 与对象存储之间的交互与前台进程解耦，确保后台操作不会影响在线流量的延时。 + +### 计算与计算分离 + +虽然经典 TiDB 已经实现了计算层（SQL 层）与存储层（TiKV）的分离，但 TiDB X 在 SQL 层和存储层内部进一步实现了更细粒度的分离，将 **轻量计算** 与 **重计算** 明确区分。 + +- **轻量计算**：专用于 OLTP 工作负载的资源，例如用户查询。 + + 对于轻量 OLTP 工作负载，由于重计算任务被卸载到弹性计算池，处理用户流量的 TiKV 服务器可以专注于在线查询处理。因此，TiDB X 能够以更少的资源提供更稳定、更可预测的性能，并确保后台任务不会干扰在线事务处理。 + +- **重计算**：用于后台任务的独立弹性计算池，例如 compaction、备份、统计信息收集、数据加载和慢查询处理。 + + 对于 DDL 操作和大规模数据导入等重计算任务，TiDB X 可以自动调度弹性计算资源，以全速运行这些工作负载，并将对在线流量的影响降到最低。例如，在创建索引时，系统会根据数据量动态调度 TiDB worker、Coprocessor worker 和 TiKV worker。这些弹性计算资源与处理在线流量的 TiDB/TiKV 服务器相互隔离，避免资源竞争。在实际场景中，索引创建速度可以比经典 TiDB 提升最多 5 倍，同时不会影响在线业务。 + +### 从 shared-nothing 到 shared-storage 的转变 + +TiDB X 从经典的 **shared-nothing（无共享）** 架构（需要在 TiKV 节点之间物理复制数据）转变为 **shared-storage（共享存储）** 架构。在 TiDB X 中，对象存储（如 Amazon S3）而非本地磁盘成为所有持久化数据的唯一来源。这一变化消除了扩缩容过程中复制大量数据的需求，实现了快速弹性扩展。 + +迁移到对象存储并不会降低前台读写性能： + +- 读操作：轻量读请求直接从本地缓存和磁盘提供服务；只有重读请求才会被卸载到远程弹性 Coprocessor worker。 +- 写操作：与对象存储的交互是异步的。Raft 日志首先持久化到本地磁盘，Raft WAL（预写式日志）块随后在后台上传到对象存储。 +- Compaction：当 MemTable 写满并 flush 到本地磁盘后，Region Leader 会将 SST 文件上传到对象存储；远程 compaction 在弹性 compaction worker 上完成后，TiKV 节点会被通知从对象存储加载合并后的 SST 文件。 + +### 弹性 TCO（按需付费） + +在经典 TiDB 中，为了同时处理高峰流量和后台任务，集群通常需要过度预配资源。TiDB X 支持 **自动扩缩容**，使用户只需为实际消耗的资源付费（按需付费）。后台任务所需的资源可以按需动态申请，任务完成后自动释放，从而避免成本浪费。 + +TiDB X 使用 [Request Capacity Unit](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)（RCU）来衡量计算能力。一个 RCU 提供固定的计算资源，可处理一定数量的 SQL 请求。用户配置的 RCU 数量决定了集群的基准性能和吞吐能力，同时可以设置上限以控制成本，并仍然享受弹性扩展带来的优势。 + +### 从 LSM tree 到 LSM forest + +在经典 TiDB 中，每个 TiKV 节点运行一个单独的 RocksDB 实例，将所有 Region 的数据混合存储在一个大的 LSM tree 中。由于来自成千上万个 Region 的数据混合在一起，在进行 Region 迁移、扩缩容等操作时往往会触发大量 compaction，从而消耗大量 CPU 和 I/O 资源，并可能影响在线流量。该单一 LSM tree 由全局 mutex 保护，当数据规模增长到较大规模时（例如单节点超过 6 TiB 数据或 30 万个 SST 文件），全局 mutex 的竞争会影响读写性能。 + +TiDB X 对存储引擎进行了重新设计，从单一 LSM tree 转变为 **LSM forest**。在保留逻辑 Region 抽象的同时，TiDB X 为每个 Region 分配独立的 LSM tree。这种物理隔离消除了跨 Region compaction 的开销，使扩缩容、Region 迁移和数据加载等操作只影响各自的树结构，不再存在全局 mutex 竞争。 + +![Classic TiDB vs TiDB X](/media/tidb-x/tidb-classic-vs-tidb-x-2.png) + +### 快速弹性扩展 + +由于数据存储在共享对象存储中，并且每个 Region 由独立的 LSM tree 管理，TiDB X 在新增或移除 TiKV 节点时无需进行物理数据迁移或大规模 compaction。因此，扩缩容操作比经典 TiDB **快 5× 至 10×**，同时能够保持在线工作负载的稳定延时。 + +## 架构对比总结 + +下表总结了从经典 TiDB 到 TiDB X 的架构转变，并说明 TiDB X 在扩展性、性能隔离和成本效率方面的改进。 + +| 特性 | 经典 TiDB | TiDB X | TiDB X 的主要收益 | +| --- | --- | --- | --- | +| 架构 | Shared-nothing（数据存储在本地磁盘） | Shared-storage（对象存储作为持久化存储） | 对象存储实现云原生弹性 | +| 稳定性 | 前台与后台任务共享资源 | 计算与计算分离（重任务使用弹性计算池） | 在高写入或维护负载下保护 OLTP 工作负载 | +| 性能 | OLTP 与后台任务争用 CPU 和 I/O | 重任务使用独立弹性资源池 | 更低的 OLTP 延时，同时加速后台任务 | +| 扩展机制 | 物理数据迁移（节点间复制 SST 文件） | TiKV 通过对象存储读写 SST 文件 | 扩缩容速度提升 5×–10× | +| 存储引擎 | 每节点单一 LSM tree（RocksDB） | LSM forest（每 Region 独立 LSM tree） | 消除全局 mutex 竞争并减少 compaction 干扰 | +| DDL 执行 | 与用户流量竞争本地 CPU/I/O | DDL 卸载到弹性计算资源 | 更快的模式变更和更稳定的延时 | +| 成本模型 | 需要按峰值过度预配 | 弹性 TCO（按需付费） | 仅为实际使用的资源付费 | +| 备份 | 与数据量相关的物理备份 | 基于元信息并集成对象存储 | 备份操作显著加速 |