From 812ab992726d5e986984d79493f405a15ab392f3 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 18 Mar 2026 11:40:29 +0000 Subject: [PATCH] [create-pull-request] automated change --- ai/_index.md | 77 ++++++ api/_index.md | 29 +++ keywords.md | 29 ++- latest_translation_commit.json | 2 +- non-transactional-dml.md | 225 ++++++++++-------- optimistic-transaction.md | 113 ++++++--- sql-statements/sql-statement-batch.md | 26 +- subquery-optimization.md | 37 +-- tidb-cloud/built-in-monitoring.md | 80 +++---- .../changefeed-sink-to-cloud-storage.md | 140 ++++++----- .../essential-changefeed-sink-to-kafka.md | 103 ++++---- tidb-cloud/import-csv-files-serverless.md | 148 ++++++------ tidb-cloud/import-csv-files.md | 144 ++++++----- tidb-cloud/import-parquet-files-serverless.md | 140 +++++------ tidb-cloud/import-parquet-files.md | 140 ++++++----- tidb-cloud/monitor-built-in-alerting.md | 46 ++-- tidb-cloud/monitor-datadog-integration.md | 76 +++--- tidb-cloud/monitor-new-relic-integration.md | 70 +++--- ...itor-prometheus-and-grafana-integration.md | 84 +++---- .../releases/tidb-cloud-release-notes.md | 100 +++++--- tidb-cloud/serverless-faqs.md | 120 +++++----- tidb-cloud/serverless-limitations.md | 33 +-- ...s-private-link-connection-to-amazon-msk.md | 157 ++++++++++++ .../serverless-private-link-connection.md | 70 ++++-- tidb-cloud/tidb-cloud-intro.md | 58 ++--- 25 files changed, 1363 insertions(+), 884 deletions(-) create mode 100644 ai/_index.md create mode 100644 api/_index.md create mode 100644 tidb-cloud/serverless-private-link-connection-to-amazon-msk.md diff --git a/ai/_index.md b/ai/_index.md new file mode 100644 index 0000000000000..5164c74ce394a --- /dev/null +++ b/ai/_index.md @@ -0,0 +1,77 @@ +--- +title: TiDB for AI +summary: 利用 TiDB 集成的向量搜索、全文搜索和无缝 Python SDK 构建现代 AI 应用。 +--- + +# TiDB for AI + +TiDB 是一款为现代 AI 应用设计的分布式 SQL 数据库，提供集成的向量搜索、全文搜索和混合搜索能力。本文档概述了使用 TiDB 构建 AI 驱动应用可用的 AI 特性与工具。 + +## 快速开始 + +快速体验 TiDB 的 AI 能力。 + +| 文档 | 描述 | +| --- | --- | +| [Get Started with Python](/ai/quickstart-via-python.md) | 使用 Python 在几分钟内构建你的第一个基于 TiDB 的 AI 应用。 | +| [Get Started with SQL](/ai/quickstart-via-sql.md) | 使用 SQL 快速开始向量搜索。 | + +## 概念 + +了解 TiDB AI 搜索的基础概念。 + +| 文档 | 描述 | +| --- | --- | +| [Vector Search](/ai/concepts/vector-search-overview.md) | 向量搜索的全面介绍，包括概念、工作原理和应用场景。 | + +## 指南 + +使用 [`pytidb`](https://github.com/pingcap/pytidb) SDK 或 SQL 构建 AI 应用的分步指南。 + +| 文档 | 描述 | +| --- | --- | +| [Connect to TiDB](/ai/guides/connect.md) | 使用 `pytidb` 连接 TiDB Cloud 或自托管集群。 | +| [Working with Tables](/ai/guides/tables.md) | 创建、查询和管理包含向量字段的表。 | +| [Vector Search](/ai/guides/vector-search.md) | 使用 `pytidb` 进行语义相似度搜索。 | +| [Full-Text Search](/ai/guides/vector-search-full-text-search-python.md) | 基于关键字的文本搜索，支持 BM25 排序。 | +| [Hybrid Search](/ai/guides/vector-search-hybrid-search.md) | 结合向量搜索与全文搜索，获得更优结果。 | +| [Image Search](/ai/guides/image-search.md) | 使用多模态嵌入进行图片搜索。 | +| [Auto Embedding](/ai/guides/auto-embedding.md) | 数据插入时自动生成嵌入向量。 | +| [Filtering](/ai/guides/filtering.md) | 通过元信息条件过滤搜索结果。 | + +## 示例 + +完整代码示例和演示，展示 TiDB 的 AI 能力。 + +| 文档 | 描述 | +| --- | --- | +| [Basic CRUD Operations](/ai/examples/basic-with-pytidb.md) | 使用 `pytidb` 进行基础表的增删改查操作。 | +| [Vector Search](/ai/examples/vector-search-with-pytidb.md) | 语义相似度搜索示例。 | +| [RAG Application](/ai/examples/rag-with-pytidb.md) | 构建检索增强生成（RAG）应用。 | +| [Image Search](/ai/examples/image-search-with-pytidb.md) | 基于 Jina AI 嵌入的多模态图片搜索。 | +| [Conversational Memory](/ai/examples/memory-with-pytidb.md) | 为 AI agent 和聊天机器人提供持久化内存。 | +| [Text-to-SQL](/ai/examples/text2sql-with-pytidb.md) | 将自然语言转换为 SQL 查询。 | + +## 集成 + +将 TiDB 与主流 AI 框架、嵌入提供商和开发工具集成。 + +| 文档 | 描述 | +| --- | --- | +| [Integration Overview](/ai/integrations/vector-search-integration-overview.md) | 所有可用集成的概览。 | +| [Embedding Providers](/ai/integrations/vector-search-auto-embedding-overview.md#available-text-embedding-models) | 为 OpenAI、Cohere、Jina AI 等提供统一接口。 | +| [LangChain](/ai/integrations/vector-search-integrate-with-langchain.md) | 将 TiDB 作为 LangChain 的向量存储。 | +| [LlamaIndex](/ai/integrations/vector-search-integrate-with-llamaindex.md) | 将 TiDB 作为 LlamaIndex 的向量存储。 | +| [MCP Server](/ai/integrations/tidb-mcp-server.md) | 将 TiDB 连接到 Claude Code、Cursor 及其他 AI 驱动的 IDE。 | + +## 参考 + +TiDB AI 与向量搜索功能的技术参考文档。 + +| 文档 | 描述 | +| --- | --- | +| [Vector Data Types](/ai/reference/vector-search-data-types.md) | 向量列类型及其用法。 | +| [Functions and Operators](/ai/reference/vector-search-functions-and-operators.md) | 距离函数与向量操作。 | +| [Vector Search Index](/ai/reference/vector-search-index.md) | 创建和管理向量索引以提升性能。 | +| [Performance Tuning](/ai/reference/vector-search-improve-performance.md) | 优化向量搜索性能。 | +| [Limitations](/ai/reference/vector-search-limitations.md) | 当前的限制与约束。 | \ No newline at end of file diff --git a/api/_index.md b/api/_index.md new file mode 100644 index 0000000000000..9c034d6d6df48 --- /dev/null +++ b/api/_index.md @@ -0,0 +1,29 @@ +--- +title: TiDB API 概览 +summary: 了解 TiDB Cloud 和 TiDB Self-Managed 可用的 API。 +--- + +# TiDB API 概览 + +TiDB 提供多种 API，用于查询和操作集群、管理数据副本、监控系统状态等。本文档概述了 [TiDB Cloud](https://docs.pingcap.com/tidbcloud/) 和 [TiDB Self-Managed](https://docs.pingcap.com/tidb/stable/) 可用的 API。 + +## TiDB Cloud API（测试版） + +[TiDB Cloud API](/api/tidb-cloud-api-overview.md) 是一种 [REST 接口](https://en.wikipedia.org/wiki/Representational_state_transfer)，为你提供以编程方式管理 TiDB Cloud 内部管理对象的能力，例如项目、集群、备份、恢复、导入、账单和 Data Service 资源。 + +| API | 描述 | +| --- | --- | +| [v1beta1](/api/tidb-cloud-api-v1beta1.md) | 管理 TiDB Cloud Starter、Essential 和 Dedicated 集群，以及账单、Data Service 和 IAM 资源。 | +| [v1beta](/api/tidb-cloud-api-v1beta.md) | 管理 TiDB Cloud 的项目、集群、备份、导入和恢复。 | + +## TiDB Self-Managed API + +TiDB Self-Managed 提供多种 API，供 TiDB 工具使用，帮助你管理集群组件、监控系统状态以及控制数据副本工作流。 + +| API | 描述 | +| --- | --- | +| [TiProxy API](/tiproxy/tiproxy-api.md) | 访问 TiProxy 配置、健康状态和监控数据。 | +| [Data Migration API](/dm/dm-open-api.md) | 管理 DM-master 和 DM-worker 节点、数据源及数据副本任务。 | +| [Monitoring API](/tidb-monitoring-api.md) | 获取 TiDB 服务器运行状态、表存储信息和 TiKV 集群详情。 | +| [TiCDC API](/ticdc/ticdc-open-api-v2.md) | 查询 TiCDC 节点状态并管理副本任务，包括创建、暂停、恢复和更新操作。 | +| [TiDB Operator API](https://github.com/pingcap/tidb-operator/blob/{{{.tidb-operator-version}}}/docs/api-references/docs.md) | 管理 Kubernetes 上的 TiDB 集群，包括部署、升级、扩缩容、备份和故障转移。 | \ No newline at end of file diff --git a/keywords.md b/keywords.md index a9fd8769b7a26..c9defddb385e6 100644 --- a/keywords.md +++ b/keywords.md @@ -1,15 +1,15 @@ --- -title: 关键词 -summary: 关键词和保留字 +title: 关键字 +summary: 关键字与保留字 --- -# 关键词 +# 关键字 -本文介绍了 TiDB 中的关键词，保留字与非保留字的区别，并总结了所有用于查询的关键词。 +本文介绍了 TiDB 中的关键字、保留字与非保留字的区别，并汇总了所有可用于查询的关键字。 -关键词是在 SQL 语句中具有特殊含义的词，例如 [`SELECT`](/sql-statements/sql-statement-select.md)、[`UPDATE`](/sql-statements/sql-statement-update.md) 和 [`DELETE`](/sql-statements/sql-statement-delete.md)。其中一些可以直接用作标识符，称为 **非保留关键词**。一些在用作标识符之前需要特殊处理，称为 **保留关键词**。 +关键字是在 SQL 语句中具有特殊含义的单词，例如 [`SELECT`](/sql-statements/sql-statement-select.md)、[`UPDATE`](/sql-statements/sql-statement-update.md) 和 [`DELETE`](/sql-statements/sql-statement-delete.md)。其中有些可以直接作为标识符使用，称为**非保留关键字**。有些则需要特殊处理后才能作为标识符使用，称为**保留关键字**。 -要将保留关键词用作标识符，必须用反引号 `` ` `` 将其括起来： +如果要将保留关键字作为标识符使用，必须用反引号 `` ` `` 包裹： ```sql CREATE TABLE select (a INT); @@ -27,7 +27,7 @@ CREATE TABLE `select` (a INT); Query OK, 0 rows affected (0.09 sec) ``` -非保留关键词不需要用反引号，例如 `BEGIN` 和 `END`，在以下语句中可以成功用作标识符： +非保留关键字无需使用反引号，例如 `BEGIN` 和 `END`，可以在如下语句中直接作为标识符使用： ```sql CREATE TABLE `select` (BEGIN int, END int); @@ -37,7 +37,7 @@ CREATE TABLE `select` (BEGIN int, END int); Query OK, 0 rows affected (0.09 sec) ``` -在特殊情况下，如果保留关键词与 `.` 分隔符一起使用，则不需要用反引号： +在特殊情况下，如果保留关键字与 `.` 分隔符一起使用，则无需加反引号： ```sql CREATE TABLE test.select (BEGIN int, END int); @@ -47,13 +47,13 @@ CREATE TABLE test.select (BEGIN int, END int); Query OK, 0 rows affected (0.08 sec) ``` -从 v7.5.3 和 v7.6.0 版本开始，TiDB 在 [`INFORMATION_SCHEMA.KEYWORDS`](/information-schema/information-schema-keywords.md) 表中提供了完整的关键词列表。 +自 v7.5.3 和 v7.6.0 起，TiDB 在 [`INFORMATION_SCHEMA.KEYWORDS`](/information-schema/information-schema-keywords.md) 表中提供了完整的关键字列表。 -你可以通过设置 [`tidb_enable_window_function`](/system-variables.md#tidb_enable_window_function) 系统变量，控制 [窗口函数](/functions-and-operators/window-functions.md) 中的关键词是否在语法树中生效。如果将 `tidb_enable_window_function` 设置为 `OFF`，窗口函数中的词将不再被视为关键词。 +你可以通过 [`tidb_enable_window_function`](/system-variables.md#tidb_enable_window_function) 系统变量控制 [窗口函数](/functions-and-operators/window-functions.md) 中的关键字是否在语法树中生效。如果将 `tidb_enable_window_function` 设置为 `OFF`，窗口函数中的单词将不再被视为关键字。 -## 关键词列表 +## 关键字列表 -以下列出了 TiDB 中的关键词。保留关键词标记为 `(R)`。用于 [窗口函数](/functions-and-operators/window-functions.md) 的保留关键词标记为 `(R-Window)`。 +下表展示了 TiDB 中的关键字。保留关键字以 `(R)` 标记。用于 [窗口函数](/functions-and-operators/window-functions.md) 的保留关键字以 `(R-Window)` 标记。 @@ -65,6 +65,7 @@ Query OK, 0 rows affected (0.08 sec) - ADMIN - ADVISE - AFTER +- AFFINITY - AGAINST - AGO - ALGORITHM @@ -409,6 +410,7 @@ Query OK, 0 rows affected (0.08 sec) M +- MASKING - MASTER - MATCH (R) - MAXVALUE (R) @@ -512,6 +514,7 @@ Query OK, 0 rows affected (0.08 sec) - PLUGINS - POINT - POLICY +- POLICIES - PRECEDING - PRECISION (R) - PREPARE @@ -789,4 +792,4 @@ Query OK, 0 rows affected (0.08 sec) Z -- ZEROFILL (R) \ No newline at end of file +- ZEROFILL (R) diff --git a/latest_translation_commit.json b/latest_translation_commit.json index 1fa2282dc0a11..fe89c027d6838 100644 --- a/latest_translation_commit.json +++ b/latest_translation_commit.json @@ -1,4 +1,4 @@ { "target": "release-8.5", - "sha": "ea728d3f449433bd0e442339b3a79cda18f453f0" + "sha": "057bc110a8eb21065dddd3dd63fdbd39ab585d5e" } \ No newline at end of file diff --git a/non-transactional-dml.md b/non-transactional-dml.md index eefd25207fb7b..872008c4a3b7c 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -1,15 +1,15 @@ --- title: 非事务性 DML 语句 -summary: 了解 TiDB 中的非事务性 DML 语句。在牺牲原子性和隔离性的情况下，将一个 DML 语句拆分成多个语句依次执行，从而提升批量数据处理场景中的稳定性和易用性。 +summary: 了解 TiDB 中的非事务性 DML 语句。以牺牲原子性和隔离性为代价，将一个 DML 语句切分为多个语句依次执行，从而提升批量数据处理场景下的稳定性和易用性。 --- # 非事务性 DML 语句 -本文档描述了 TiDB 中非事务性 DML 语句的使用场景、使用方法及限制。此外，还将说明其实现原理和常见问题。 +本文档介绍了 TiDB 中非事务性 DML 语句的使用场景、使用方法和限制条件，并对其实现原理及常见问题进行了说明。 -非事务性 DML 语句是将一个 DML 语句拆分成多个 SQL 语句（即多个批次）依次执行的方式。它在提升批量数据处理性能和易用性的同时，牺牲了事务的原子性和隔离性。 +非事务性 DML 语句是将一个 DML 语句切分为多个 SQL 语句（即多个批次）依次执行。它以牺牲事务的原子性和隔离性为代价，提升了批量数据处理的性能和易用性。 -通常，内存占用较大的事务需要拆分成多个 SQL 语句以绕过事务大小限制。非事务性 DML 将这一过程集成到 TiDB 内核中，实现相同效果。理解通过拆分 SQL 语句的非事务性 DML 语句的效果，有助于优化批量操作。可以使用 `DRY RUN` 语法预览拆分后的语句。 +通常，内存消耗较大的事务需要手动切分为多个 SQL 语句，以绕过事务大小限制。非事务性 DML 语句将这一过程集成到 TiDB 内核中，实现同样的效果。通过切分 SQL 语句，有助于理解非事务性 DML 语句的效果。可以使用 `DRY RUN` 语法预览切分后的语句。 非事务性 DML 语句包括： @@ -18,42 +18,42 @@ summary: 了解 TiDB 中的非事务性 DML 语句。在牺牲原子性和隔离 - `UPDATE` - `DELETE` -详细语法请参见 [`BATCH`](/sql-statements/sql-statement-batch.md)。 +详细语法参见 [`BATCH`](/sql-statements/sql-statement-batch.md)。 > **注意：** > -> - 非事务性 DML 语句不保证语句的原子性和隔离性，不等同于原始的 DML 语句。 -> - 将 DML 语句重写为非事务性 DML 后，不应假设其行为与原始语句完全一致。 -> - 在使用非事务性 DML 前，需要分析拆分的语句是否会相互影响。 +> - 非事务性 DML 语句不保证语句的原子性和隔离性，并不等价于原始 DML 语句。 +> - DML 语句被重写为非事务性 DML 语句后，不能假设其行为与原始语句一致。 +> - 在使用非事务性 DML 前，需要分析切分后的语句是否会相互影响。 ## 使用场景 -在大数据处理场景中，常常需要对大量数据执行相同操作。如果直接用单个 SQL 语句执行，可能会超出事务大小限制，影响执行性能。 +在大数据处理场景下，通常需要对大量数据进行相同操作。如果直接使用单条 SQL 语句操作，可能会因事务大小超限而影响执行性能。 -批量数据处理通常与线上应用操作没有时间或数据上的重叠。在没有并发操作的情况下，隔离（ACID 中的 I）是不必要的。如果批量数据操作是幂等的或易于重试，也不需要保证原子性。如果你的应用不需要数据隔离或原子性，可以考虑使用非事务性 DML。 +批量数据处理通常与在线应用操作在时间或数据上没有重叠。当不存在并发操作时，隔离性（ACID 中的 I）并非必需。如果批量数据操作是幂等的或易于重试，原子性也不是必须的。如果你的应用既不需要数据隔离，也不需要原子性，可以考虑使用非事务性 DML 语句。 -非事务性 DML 主要用于绕过某些场景下的大事务大小限制。用一条语句完成本需手动拆分事务的任务，提升执行效率，减少资源消耗。 +非事务性 DML 语句用于在特定场景下绕过大事务的大小限制。只需一条语句即可完成原本需要手动切分事务的任务，执行效率更高，资源消耗更少。 -例如，为了删除过期数据，如果确保没有应用访问过期数据，可以用非事务性 DML 提高 `DELETE` 的性能。 +例如，删除过期数据时，如果你能确保没有应用会访问这些过期数据，可以使用非事务性 DML 语句提升 `DELETE` 的性能。 ## 前提条件 在使用非事务性 DML 语句前，请确保满足以下条件： -- 语句不需要原子性，允许部分行被修改，部分行保持不变。 -- 语句是幂等的，或你已准备好根据错误信息对部分数据进行重试。如果系统变量 `tidb_redact_log = 1` 和 `tidb_nontransactional_ignore_error = 1`，则此语句必须是幂等的，否则部分失败时无法准确定位失败部分。 -- 操作的数据没有其他并发写入，即不会被其他语句同时更新，否则可能出现遗漏写入、错误写入或多次修改同一行的情况。 -- 语句不修改自己要读取的数据，否则后续批次会读取前一批写入的数据，容易导致意外结果。 +- 语句不需要原子性，允许部分行被修改，部分行未被修改。 +- 语句是幂等的，或者你已准备好根据错误信息对部分数据进行重试。如果系统变量设置为 `tidb_redact_log = 1` 且 `tidb_nontransactional_ignore_error = 1`，则该语句必须是幂等的。否则，当语句部分失败时，无法准确定位失败部分。 +- 待操作的数据没有其他并发写入，即不会被其他语句同时 update。否则，可能出现漏写、错写、同一行被多次 update 等异常结果。 +- 语句不会 update 自身需要 read 的数据。否则，后续批次会 read 到前一批次写入的数据，容易导致异常结果。 - - 避免在非事务性 `INSERT INTO ... SELECT` 语句中同时修改同一表的分片列，否则多批次可能读取相同的行并多次插入： - - 不建议使用 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id+1, value FROM t;`。 + - 当在非事务性 `INSERT INTO ... SELECT` 语句中对同一表进行 select 和 update 时，避免 update 分片列。否则，多个批次可能会 read 到同一行并多次插入数据： + - 不推荐使用 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id+1, value FROM t;`。 - 推荐使用 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id, value FROM t;`。 - - 如果分片列 `id` 具有 `AUTO_INCREMENT` 属性，建议使用 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t(value) SELECT value FROM t;`。 - - 避免在非事务性 `UPDATE`、`INSERT ... ON DUPLICATE KEY UPDATE` 或 `REPLACE INTO` 语句中修改分片列： - - 例如，非事务性 `UPDATE` 语句，拆分的 SQL 语句依次执行，前一批的修改在下一批提交后被读取，导致同一行数据被多次修改。 + - 如果分片列 `id` 有 `AUTO_INCREMENT` 属性，推荐使用 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t(value) SELECT value FROM t;`。 + - 避免在非事务性 `UPDATE`、`INSERT ... ON DUPLICATE KEY UPDATE` 或 `REPLACE INTO` 语句中 update 分片列： + - 例如，对于非事务性 `UPDATE` 语句，切分后的 SQL 语句依次执行。前一批次的 update 会被后一批次 read 到，导致同一行数据被多次 update。 - 这些语句不支持 `BATCH ON test.t.id LIMIT 10000 UPDATE t SET test.t.id = test.t.id-1;`。 - - 不建议使用 `BATCH ON test.t.id LIMIT 1 INSERT INTO t SELECT id+1, value FROM t ON DUPLICATE KEY UPDATE id = id + 1;`。 - - 分片列不应作为 Join 键。例如，以下示例使用 `test.t.id` 作为 Join 键，导致非事务性 `UPDATE` 多次修改同一行： + - 不推荐使用 `BATCH ON test.t.id LIMIT 1 INSERT INTO t SELECT id+1, value FROM t ON DUPLICATE KEY UPDATE id = id + 1;`。 + - 分片列不应作为 Join 键。例如，以下示例将分片列 `test.t.id` 作为 Join 键，导致非事务性 `UPDATE` 语句多次 update 同一行： ```sql CREATE TABLE t(id int, v int, key(id)); @@ -64,20 +64,20 @@ summary: 了解 TiDB 中的非事务性 DML 语句。在牺牲原子性和隔离 SELECT * FROM t2; -- (4, 1) (4, 2) (4, 4) ``` -- 语句符合 [`restrictions`](#restrictions)。 -- 不建议对将被此 DML 语句读写的表进行并发 DDL 操作。 +- 语句满足[限制条件](#限制条件)。 +- 不推荐对该 DML 语句需要 read 或写入的表并发执行 DDL 操作。 -> **Warning:** +> **警告：** > -> 如果同时开启 `tidb_redact_log` 和 `tidb_nontransactional_ignore_error`，可能无法获取每个批次的完整错误信息，也不能只重试失败的批次。因此，两个系统变量同时开启时，非事务性 DML 语句必须是幂等的。 +> 如果同时开启了 `tidb_redact_log` 和 `tidb_nontransactional_ignore_error`，你可能无法获得每个批次的完整错误信息，也无法只重试失败的批次。因此，如果这两个系统变量都开启，非事务性 DML 语句必须是幂等的。 ## 使用示例 ### 使用非事务性 DML 语句 -以下部分介绍非事务性 DML 语句的使用方法及示例： +以下部分通过示例介绍非事务性 DML 语句的用法： -创建表 `t`，结构如下： +创建表 `t`，表结构如下： ```sql @@ -99,7 +99,7 @@ INSERT INTO t VALUES (1, 2), (2, 3), (3, 4), (4, 5), (5, 6); Query OK, 5 rows affected ``` -以下操作使用非事务性 DML 语句删除 `v` 列值小于 6 的行。此语句拆分为两个 SQL 语句，批次大小为 2，按 `id` 列分片执行。 +以下操作使用非事务性 DML 语句，删除表 `t` 的 `v` 列值小于整数型 6 的行。该语句被切分为两条 SQL 语句，批次大小为 2，按 `id` 列分片并执行。 ```sql @@ -115,7 +115,7 @@ BATCH ON id LIMIT 2 DELETE FROM t WHERE v < 6; 1 row in set ``` -检查上述非事务性 DML 语句的删除结果。 +查看上述非事务性 DML 语句的删除结果。 ```sql @@ -131,14 +131,14 @@ SELECT * FROM t; 1 row in set ``` -以下示例描述如何使用多表连接。首先，创建表 `t2` 并插入数据： +以下示例介绍多表 Join 的用法。首先创建表 `t2` 并插入数据： ```sql CREATE TABLE t2(id int, v int, key(id)); INSERT INTO t2 VALUES (1,1), (3,3), (5,5); ``` -然后，通过连接表 `t` 和 `t2` 更新 `t2` 中的数据。注意需要指定分片列以及完整的数据库名、表名和列名（`test.t.id`）： +然后通过 Join 表 `t` 和 `t2` update 表 `t2` 的数据。注意需要指定分片列，并带上完整的数据库名、表名和列名（`test.t.id`）： ```sql BATCH ON test.t._tidb_rowid LIMIT 1 UPDATE t JOIN t2 ON t.id = t2.id SET t2.id = t2.id+1; @@ -162,7 +162,7 @@ SELECT * FROM t2; ### 查看执行进度 -在执行非事务性 DML 语句期间，可以使用 `SHOW PROCESSLIST` 查看进度。返回结果中的 `Time` 字段表示当前批次执行的耗时。日志和慢日志也会记录每个拆分语句的执行进度。例如： +在非事务性 DML 语句执行过程中，可以通过 `SHOW PROCESSLIST` 查看进度。返回结果中的 `Time` 字段表示当前批次的执行耗时。日志和慢日志也会记录整个非事务性 DML 执行过程中每个切分语句的进度。例如： ```sql @@ -180,15 +180,15 @@ SHOW PROCESSLIST; ### 终止非事务性 DML 语句 -可以使用 `KILL TIDB ` 来终止非事务性 DML 语句。TiDB 会取消当前正在执行的批次之后的所有批次。可以从日志中获取执行结果。 +要终止非事务性 DML 语句，可以使用 `KILL TIDB `。此时 TiDB 会在当前批次执行完成后，取消后续所有批次。你可以从日志中获取执行结果。 -关于 `KILL TIDB` 的更多信息，请参见参考 [`KILL`](/sql-statements/sql-statement-kill.md)。 +关于 `KILL TIDB` 的更多信息，参见参考文档 [`KILL`](/sql-statements/sql-statement-kill.md)。 -### 查询批次划分语句 +### 查询切分批次的语句 -在执行非事务性 DML 语句期间，系统会内部使用一条语句将 DML 语句拆分成多个批次。可以在此非事务性 DML 语句中添加 `DRY RUN QUERY` 来查询此批次划分语句。这样 TiDB 不会执行此查询及后续的 DML 操作。 +在非事务性 DML 语句执行过程中，内部会用一条语句将 DML 语句切分为多个批次。要查询该切分语句，可以在非事务性 DML 语句中添加 `DRY RUN QUERY`。此时 TiDB 不会执行该查询及后续 DML 操作。 -例如，查询 `BATCH ON id LIMIT 2 DELETE FROM t WHERE v < 6` 执行期间的批次划分语句： +以下语句用于查询 `BATCH ON id LIMIT 2 DELETE FROM t WHERE v < 6` 执行过程中的切分语句： ```sql @@ -204,11 +204,10 @@ BATCH ON id LIMIT 2 DRY RUN QUERY DELETE FROM t WHERE v < 6; 1 row in set ``` -### 查询对应第一个和最后一个批次的语句 +### 查询首尾批次对应的语句 -要查询非事务性 DML 语句中第一个和最后一个批次对应的实际 DML 语句，可以在此非事务性 DML 语句中添加 `DRY RUN`。这样 TiDB 只会拆分批次，不会执行这些 SQL 语句。由于批次数量可能较多，只会显示第一个和最后一个批次。 +要查询非事务性 DML 语句中首批和末批实际对应的 DML 语句，可以在该语句中添加 `DRY RUN`。此时 TiDB 只进行批次切分，不会执行这些 SQL 语句。由于批次数可能很多，不会全部展示，只展示首批和末批。 -例如： ```sql BATCH ON id LIMIT 2 DRY RUN DELETE FROM t WHERE v < 6; @@ -224,9 +223,9 @@ BATCH ON id LIMIT 2 DRY RUN DELETE FROM t WHERE v < 6; 2 rows in set ``` -### 使用优化器提示 +### 使用优化器 Hint -如果在 `DELETE` 语句中原本支持优化器提示，则在非事务性 `DELETE` 语句中也支持。提示的位置与普通 `DELETE` 语句相同： +如果 `DELETE` 语句原本支持优化器 Hint，则非事务性 `DELETE` 语句同样支持。Hint 的位置与普通 `DELETE` 语句一致： ```sql @@ -235,94 +234,95 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; ## 最佳实践 -为了使用非事务性 DML 语句，建议按照以下步骤操作： +使用非事务性 DML 语句时，推荐按照以下步骤操作： -1. 选择合适的 [`shard column`](#parameter-description)。推荐使用整数或字符串类型。 -2. 在非事务性 DML 语句中添加 `DRY RUN QUERY`，手动执行查询，确认 DML 语句影响的数据范围大致正确。 -3. 在非事务性 DML 语句中添加 `DRY RUN`，手动执行查询，检查拆分的语句和执行计划。注意以下几点： +1. 选择合适的[分片列](#参数说明)。推荐使用整数型或字符串类型。 +2. 在非事务性 DML 语句中添加 `DRY RUN QUERY`，手动执行并确认 DML 语句影响的数据范围大致正确。 +3. 在非事务性 DML 语句中添加 `DRY RUN`，手动执行并检查切分后的语句及执行计划。需要关注以下几点： - - 拆分的语句是否能读取到前一批写入的结果，可能引发异常。 + - 切分后的语句是否会 read 到前一语句写入的结果，可能导致异常。 - 索引的选择性。 - - TiDB 自动选择的分片列是否会被修改。 + - TiDB 自动选择的分片列是否会被 update。 4. 执行非事务性 DML 语句。 -5. 如果出现错误，从错误信息或日志中获取具体失败的数据范围，进行重试或手动处理。 +5. 如果报错，根据错误信息或日志获取具体失败的数据范围，并重试或手动处理。 ## 参数说明 -| 参数 | 描述 | 默认值 | 必填 | 推荐值 | +| 参数 | 说明 | 默认值 | 是否必填 | 推荐值 | | :-- | :-- | :-- | :-- | :-- | -| Shard column | 用于分片批次的列，例如上述非事务性 DML 语句 `BATCH ON id LIMIT 2 DELETE FROM t WHERE v < 6` 中的 `id` 列。 | TiDB 尝试自动选择分片列（不推荐）。 | 否 | 选择一个能满足 `WHERE` 条件且效率较高的列。 | -| Batch size | 用于控制每个批次的大小。拆分成的 SQL 语句数量即为 DML 操作的批次数，例如上述非事务性 DML 语句中的 `LIMIT 2`。批次越多，单个批次越小。 | N/A | 是 | 1000-1000000。批次过小或过大都会导致性能下降。 | +| 分片列 | 用于批次分片的列，如上述非事务性 DML 语句 `BATCH ON id LIMIT 2 DELETE FROM t WHERE v < 6` 中的 `id` 列。 | TiDB 会尝试自动选择分片列（不推荐）。 | 否 | 选择能以最高效方式满足 `WHERE` 条件的列。 | +| 批次大小 | 用于控制每个批次的大小。批次数即 DML 操作被切分为的 SQL 语句数，如上述非事务性 DML 语句 `BATCH ON id LIMIT 2 DELETE FROM t WHERE v < 6` 中的 `LIMIT 2`。批次数越多，单批次越小。 | N/A | 是 | 1000-1000000。批次过小或过大都会导致性能下降。 | ### 如何选择分片列 -非事务性 DML 语句以某列作为数据拆分的依据，即分片列。为了提高执行效率，分片列应使用索引。不同索引和分片列带来的执行效率可能相差数十倍。在选择分片列时，建议考虑以下建议： +非事务性 DML 语句会以某一列为数据分批依据，即分片列。为提升执行效率，分片列需使用索引。不同索引和分片列带来的执行效率可能相差数十倍。选择分片列时，建议参考以下建议： -- 如果你了解应用的数据分布，根据 `WHERE` 条件，选择拆分后范围较小的列。 - - 理想情况下，`WHERE` 条件能利用分片列的索引，减少每批扫描的数据量。例如，有一张事务表记录每笔事务的开始和结束时间，你想删除所有结束时间在一个月前的事务记录。如果事务的开始时间有索引，且开始和结束时间相对接近，可以选择开始时间列作为分片列。 - - 在不理想的情况下，分片列的数据分布与 `WHERE` 条件完全无关，索引无法减少扫描范围。 -- 存在聚簇索引时，建议使用主键（包括 `INT` 主键和 `_tidb_rowid`）作为分片列，以提升效率。 +- 如果你了解应用数据分布，可根据 `WHERE` 条件选择分批后数据范围较小的列。 + - 理想情况下，`WHERE` 条件能利用分片列的索引，减少每批次需要扫描的数据量。例如，有一张记录事务起止时间的交易表，需要删除所有结束时间早于一个月前的交易记录。如果事务起始时间有索引，且起止时间相近，则可选择起始时间列作为分片列。 + - 非理想情况下，分片列的数据分布与 `WHERE` 条件完全无关，分片列的索引无法缩小数据扫描范围。 +- 存在聚簇索引时，推荐使用主键（包括 `INT` 主键和 `_tidb_rowid`）作为分片列，执行效率更高。 - 选择重复值较少的列。 -你也可以选择不指定分片列。此时，TiDB 默认使用 `handle` 的第一个列作为分片列。但如果主键的第一个列类型不支持非事务性 DML（如 `ENUM`、`BIT`、`SET`、`JSON`），则会报错。可以根据应用需求选择合适的分片列。 +你也可以不指定分片列，此时 TiDB 默认使用 `handle` 的第一列作为分片列。但如果聚簇索引主键的第一列为非事务性 DML 语句不支持的数据类型（即 `ENUM`、`BIT`、`SET`、`JSON`），TiDB 会报错。你可以根据应用需求选择合适的分片列。 ### 如何设置批次大小 -在非事务性 DML 语句中，批次越大，拆分的 SQL 语句越少，每个 SQL 执行越慢。最优批次大小依赖于工作负载。建议从 50000 开始。批次过小或过大都可能导致性能下降。 +在非事务性 DML 语句中，批次越大，切分出的 SQL 语句越少，每条 SQL 语句执行越慢。最优批次大小取决于具体 workload，建议从 50000 开始尝试。批次过小或过大都会导致执行效率下降。 -每个批次的信息存储在内存中，批次数过多会显著增加内存消耗。这也是为什么批次不能太小的原因。存储批次信息的最大内存限制与 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 相同，超出此限制会触发 [`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610) 的配置行为。 +每个批次的信息会存储在内存中，因此批次数过多会显著增加内存消耗，这也是批次不能过小的原因。非事务性语句用于存储批次信息的内存上限与 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 相同，超限时触发的行为由配置项 [`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610) 决定。 -## 限制 +## 限制条件 -以下是对非事务性 DML 语句的硬性限制。如果不满足这些限制，TiDB 会报错。 +以下为非事务性 DML 语句的硬性限制条件，不满足时 TiDB 会报错。 - DML 语句不能包含 `ORDER BY` 或 `LIMIT` 子句。 - 不支持子查询或集合操作。 -- 分片列必须有索引。索引可以是单列索引，也可以是联合索引的第一个列。 +- 分片列必须有索引。该索引可以是单列索引，也可以是联合索引的第一列。 - 必须在 [`autocommit`](/system-variables.md#autocommit) 模式下使用。 -- 在启用批量 DML 时不能使用。 -- 在设置了 [`tidb_snapshot`](/read-historical-data.md) 时不能使用。 -- 不能与 `prepare` 语句配合使用。 -- 不支持 `ENUM`、`BIT`、`SET`、`JSON` 类型作为分片列。 -- 不支持 [临时表](/temporary-tables.md)。 -- 不支持 [公共表表达式](/develop/dev-guide-use-common-table-expression.md)。 +- 启用 batch-dml 时不能使用。 +- 设置了 [`tidb_snapshot`](/read-historical-data.md) 时不能使用。 +- 不能与 prepare 语句一起使用。 +- `ENUM`、`BIT`、`SET`、`JSON` 类型不支持作为分片列。 +- 不支持[临时表](/temporary-tables.md)。 +- 不支持 [Common Table Expression](/develop/dev-guide-use-common-table-expression.md)。 ## 控制批次执行失败 -非事务性 DML 语句不满足原子性，部分批次可能成功，部分批次失败。系统变量 [`tidb_nontransactional_ignore_error`](/system-variables.md#tidb_nontransactional_ignore_error-new-in-v610) 控制非事务性 DML 语句的错误处理方式。 +非事务性 DML 语句不满足原子性，部分批次可能成功，部分批次可能失败。系统变量 [`tidb_nontransactional_ignore_error`](/system-variables.md#tidb_nontransactional_ignore_error-new-in-v610) 控制非事务性 DML 语句如何处理错误。 -例外情况是，若第一批次失败，很可能语句本身有误，此时整个非事务性语句会直接返回错误。 +有一个例外：如果首批失败，很大概率是语句本身有误，此时整个非事务性语句会直接返回错误。 -## 工作原理 +## 实现原理 -非事务性 DML 语句的工作原理是将 SQL 语句的自动拆分功能内置到 TiDB 中。没有非事务性 DML 时，你需要手动拆分 SQL 语句。理解非事务性 DML 的行为，可以将其视为用户脚本执行以下任务： +非事务性 DML 语句的工作原理是将 SQL 语句自动切分内置到 TiDB 中。如果没有非事务性 DML 语句，你需要手动切分 SQL 语句。理解非事务性 DML 语句的行为，可以将其类比为用户脚本完成如下任务： -对于非事务性 DML `BATCH ON $C$ LIMIT $N$ DELETE FROM ... WHERE $P$`，$C$ 为拆分列，$N$ 为批次大小，$P$ 为过滤条件。 +对于非事务性 DML `BATCH ON $C$ LIMIT $N$ DELETE FROM ... WHERE $P$`，$C$ 为分片列，$N$ 为批次大小，$P$ 为过滤条件。 -1. 根据原始语句的过滤条件 $P$ 和指定的拆分列 $C$，TiDB 查询满足 $P$ 的所有 $C$。TiDB 根据 $N$ 将这些 $C$ 分组为 $B_1 \dots B_k$，并在每个组中保留第一个和最后一个 $C$，记为 $S_i$ 和 $E_i$。此步骤执行的查询语句可通过 [`DRY RUN QUERY`](/non-transactional-dml.md#query-the-batch-dividing-statement) 查看。 -2. $B_i$ 涉及的数据是满足 $P_i$：$C$ BETWEEN $S_i$ AND $E_i$ 的子集。可以用 $P_i$ 缩小每个批次需要处理的数据范围。 -3. 对于 $B_i$，将上述条件嵌入到原始语句的 `WHERE` 条件中，即变为 WHERE ($P_i$) AND ($P$)。此步骤的执行结果可通过 [`DRY RUN`](/non-transactional-dml.md#query-the-statements-corresponding-to-the-first-and-the-last-batches) 查看。 -4. 对所有批次依次执行新语句。每个分组的错误会被收集并合并，作为所有分组完成后的整个非事务性 DML 语句的结果返回。 +1. 根据原始语句的过滤条件 $P$ 和指定的分片列 $C$，TiDB 查询所有满足 $P$ 的 $C$。TiDB 按 $N$ 将这些 $C$ 分组为 $B_1 \dots B_k$，每个 $B_i$ 记录首尾 $C$，分别为 $S_i$ 和 $E_i$。该步骤执行的查询语句可通过 [`DRY RUN QUERY`](/non-transactional-dml.md#查询切分批次的语句) 查看。 +2. $B_i$ 涉及的数据为满足 $P_i$ 的子集：$C$ BETWEEN $S_i$ AND $E_i$。可用 $P_i$ 缩小每批次需要处理的数据范围。 +3. 对于 $B_i$，TiDB 将上述条件嵌入原始语句的 `WHERE` 条件，使其变为 WHERE ($P_i$) AND ($P$)。该步骤的执行结果可通过 [`DRY RUN`](/non-transactional-dml.md#查询首尾批次对应的语句) 查看。 +4. 对所有批次，依次执行新语句。每个分组的错误会被收集和合并，所有分组完成后作为整个非事务性 DML 语句的结果返回。 ## 与 batch-dml 的对比 -batch-dml 是在执行 DML 语句期间，将事务拆分成多个事务提交的机制。 +batch-dml 是在 DML 语句执行过程中，将一个事务切分为多次事务提交的机制。 -> **Note:** +> **注意：** > -> 不建议使用已废弃的 batch-dml。当 batch-dml 功能未正确使用时，存在数据索引不一致的风险。 +> 不推荐使用已废弃的 batch-dml。batch-dml 特性使用不当时存在数据索引不一致的风险。 + +非事务性 DML 语句尚不能完全替代所有 batch-dml 的使用场景。两者主要区别如下： -非事务性 DML 语句尚不能完全取代所有 batch-dml 使用场景。它们的主要区别如下： +- 性能：当[分片列](#如何选择分片列)高效时，非事务性 DML 语句的性能接近 batch-dml。当分片列效率较低时，非事务性 DML 语句的性能明显低于 batch-dml。 -- 性能：当 [`shard column`](#how-to-select-a-shard-column) 高效时，非事务性 DML 的性能接近 batch-dml；当 shard column 效率较低时，性能明显低于 batch-dml。 -- 稳定性：batch-dml 容易因不当使用导致数据索引不一致。非事务性 DML 不会引发数据索引不一致，但不当使用时，行为可能与原始语句不符，应用可能观察到异常行为。详见 [常见问题部分](#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete)。 +- 稳定性：batch-dml 易因使用不当导致数据索引不一致。非事务性 DML 语句不会导致数据索引不一致。但使用不当时，非事务性 DML 语句并不等价于原始语句，应用可能观察到异常行为。详见[常见问题](#非事务性-delete-存在与普通-delete-不等价的“异常”行为)章节。 ## 常见问题 -### 执行多表连接语句时出现 `Unknown column xxx in 'where clause'` 错误 +### 执行多表 Join 语句报错 `Unknown column xxx in 'where clause'` -当查询中的 `WHERE` 子句涉及除定义了 [shard column](#parameter-description) 的表之外的其他表时，会出现此错误。例如，以下 SQL 语句中，分片列为 `t2.id`，定义在表 `t2`，但 `WHERE` 子句涉及 `t2` 和 `t3`。 +当查询中拼接的 `WHERE` 子句涉及的表不包含[分片列](#参数说明)定义的表时，会出现该错误。例如，以下 SQL 语句的分片列为 `t2.id`，定义在表 `t2`，但 `WHERE` 子句涉及表 `t2` 和 `t3`。 ```sql BATCH ON test.t2.id LIMIT 1 @@ -334,7 +334,7 @@ SELECT t2.id, t2.v, t3.id FROM t2, t3 WHERE t2.id = t3.id (1054, "Unknown column 't3.id' in 'where clause'") ``` -出现此错误时，可以用 `DRY RUN QUERY` 打印确认查询语句，例如： +如遇该错误，可通过 `DRY RUN QUERY` 打印查询语句进行确认。例如： ```sql BATCH ON test.t2.id LIMIT 1 @@ -342,7 +342,7 @@ DRY RUN QUERY INSERT INTO t SELECT t2.id, t2.v, t3.id FROM t2, t3 WHERE t2.id = t3.id ``` -为避免此错误，可以将涉及其他表的条件移到 `JOIN` 的 `ON` 条件中，例如： +为避免该错误，可将 `WHERE` 子句中涉及其他表的条件移至 `JOIN` 子句的 `ON` 条件。例如： ```sql BATCH ON test.t2.id LIMIT 1 @@ -358,44 +358,65 @@ SELECT t2.id, t2.v, t3.id FROM t2 JOIN t3 ON t2.id = t3.id +----------------+---------------+ ``` +### 非事务性 DML 语句使用表别名时报错 `Unknown column '.' in 'where clause'` + +执行非事务性 DML 语句时，TiDB 内部会构造一条用于切分批次的查询语句，并生成实际切分后的执行语句。你可以分别使用 [`DRY RUN QUERY`](/non-transactional-dml.md#查询切分批次的语句) 和 [`DRY RUN`](/non-transactional-dml.md#查询首尾批次对应的语句) 查看这两类语句。 + +当前版本中，重写后的语句可能不会保留原始 DML 语句中的表别名。因此，如果你在 `WHERE` 子句或其他表达式中使用 `.` 格式引用列，可能会出现 `Unknown column` 错误。 + +例如，以下语句在某些情况下可能报错： + +```sql +BATCH ON t_old.id LIMIT 5000 +INSERT INTO t_new +SELECT * FROM t_old AS t +WHERE t.c1 IS NULL; +``` + +为避免该错误，建议： + +- 避免在非事务性 DML 语句中使用表别名。例如，将 `t.c1` 改为 `c1` 或 `t_old.c1`。 +- 指定[分片列](#参数说明)时不要使用表别名。例如，将 `BATCH ON t.id` 改为 `BATCH ON db.t_old.id` 或 `BATCH ON t_old.id`。 +- 执行前使用 `DRY RUN QUERY` 或 `DRY RUN` 预览重写后的语句，确认其符合预期。 + ### 实际批次大小与指定批次大小不一致 -在执行非事务性 DML 语句时，最后一个批次处理的数据可能少于指定的批次大小。 +在非事务性 DML 语句执行过程中，最后一个批次需要处理的数据量可能小于指定的批次大小。 -当**分片列存在重复值**时，每个批次会包含该批次最后一个元素的所有重复值，因此此批次的行数可能大于指定的批次大小。 +当**分片列存在重复值**时，每个批次会包含该批次分片列最后一个元素的所有重复值。因此，该批次的行数可能大于指定的批次大小。 -此外，当存在其他并发写入时，每个批次处理的行数也可能与指定的批次大小不同。 +此外，若存在其他并发写入，每个批次实际处理的行数也可能与指定批次大小不同。 -### 执行过程中出现 `Failed to restore the delete statement, probably because of unsupported type of the shard column` 错误 +### 执行时报错 `Failed to restore the delete statement, probably because of unsupported type of the shard column` -分片列不支持 `ENUM`、`BIT`、`SET`、`JSON` 类型。建议指定新的分片列，推荐使用整数或字符串类型。 +分片列不支持 `ENUM`、`BIT`、`SET`、`JSON` 类型。请尝试指定新的分片列。推荐使用整数型或字符串类型的列。 -如果在选择的分片列不是上述不支持类型时出现此错误，可以 [获取支持](/support.md) 来自 PingCAP 或社区。 +如果选择的分片列不是上述不支持的类型仍报错，请[获取支持](/support.md) 或联系社区。 -如果在选择的分片列不是上述不支持类型时出现此错误，可以 [联系 TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 +如果选择的分片列不是上述不支持的类型仍报错，请[联系 TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 -### 非事务性 `DELETE` 存在“异常”行为，不等同于普通 `DELETE` +### 非事务性 `DELETE` 存在与普通 `DELETE` 不等价的“异常”行为 -非事务性 DML 语句不等同于原始的 DML 语句，可能存在以下原因： +非事务性 DML 语句并不等价于该 DML 语句的原始形式，可能有如下原因： - 存在其他并发写入。 -- 非事务性 DML 语句修改了语句自身会读取的值。 -- 每个批次执行的 SQL 语句可能导致不同的执行计划和表达式计算顺序，因此执行结果可能与原始语句不同。 +- 非事务性 DML 语句 update 了自身会 read 的值。 +- 每个批次执行的 SQL 语句因 `WHERE` 条件变化，可能导致执行计划和表达式计算顺序不同，因此执行结果可能与原始语句不同。 - DML 语句包含非确定性操作。 ## MySQL 兼容性 非事务性语句为 TiDB 特有，不兼容 MySQL。 -## 相关链接 +## 参考文档 * [`BATCH`](/sql-statements/sql-statement-batch.md) 语法 * [`tidb_nontransactional_ignore_error`](/system-variables.md#tidb_nontransactional_ignore_error-new-in-v610) diff --git a/optimistic-transaction.md b/optimistic-transaction.md index efdac6abb1f70..2cb25fb277acd 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -1,50 +1,99 @@ --- -title: TiDB Optimistic Transaction Model +title: TiDB 乐观事务模型 summary: 了解 TiDB 中的乐观事务模型。 --- # TiDB 乐观事务模型 -在乐观事务中，冲突的变更会在事务提交阶段被检测到。当并发事务很少修改相同行时，这有助于提升性能，因为可以跳过获取行锁的过程。如果并发事务频繁修改相同行（即发生冲突），乐观事务的性能可能会比 [悲观事务](/pessimistic-transaction.md) 更差。 +在乐观事务中，**冲突**的变更会在事务提交阶段被检测出来。当并发事务很少修改同一行时，这有助于提升性能，因为可以跳过获取行锁的过程。如果并发事务频繁修改同一行（发生**冲突**），乐观事务的性能可能会比 [悲观事务](/pessimistic-transaction.md) 更差。 -在启用乐观事务前，请确保你的应用程序能够正确处理 `COMMIT` 语句可能返回的错误。如果你不确定应用程序的处理方式，建议使用悲观事务。 +在启用乐观事务之前，请确保你的应用程序能够正确**处理** `COMMIT` 语句可能**返回**的错误。如果你不确定应用程序如何处理这种情况，建议使用悲观事务。 > **注意：** > -> 从 v3.0.8 开始，TiDB 默认使用 [悲观事务模式](/pessimistic-transaction.md)。但如果你是从 v3.0.7 或更早版本升级到 v3.0.8 或更高版本，这一更改不会影响现有集群。换句话说，**只有新创建的集群默认使用悲观事务模式**。 +> 从 v3.0.8 版本开始，TiDB 默认使用 [悲观事务模式](/pessimistic-transaction.md)。但如果你是从 v3.0.7 或更早版本升级到 v3.0.8 或更高版本，则不会影响你现有的**集群**。换句话说，**只有新创建的集群默认使用悲观事务模式**。 ## 乐观事务的原理 -为支持分布式事务，TiDB 在乐观事务中采用了两阶段提交（2PC）。流程如下： +为了支持分布式事务，TiDB 在乐观事务中采用了两阶段提交（2PC）。流程如下： -![2PC in TiDB](/media/2pc-in-tidb.png) +```mermaid +--- +title: 2PC in TiDB +--- +sequenceDiagram + participant client + participant TiDB + participant PD + participant TiKV + + client->>TiDB: begin + TiDB->>PD: get ts as start_ts + + loop excute SQL + alt do read + TiDB->>PD: get region from PD or cache + TiDB->>TiKV: get data from TiKV or cache with start_ts + TiDB-->>client: return read result + end + alt do write + TiDB-->>TiDB: write in cache + TiDB-->>client: return write result + end + end + + client->>TiDB: commit + + opt start 2PC + TiDB-->>TiDB: for all keys need to write,choose first one as primary + TiDB->>PD: locate each key + TiDB-->>TiDB: group keys by region to [](region,keys) + + opt prewrite with start_ts + TiDB->>TiKV: prewrite(primary_key,start_ts) + loop prewrite to each region in [](region,keys) parallelly + TiDB->>TiKV: prewrite(keys,primary_key,start_ts) + end + end + + opt commit + TiDB-->>PD: get ts as commit_ts + TiDB-->>TiKV: commit primary with commit_ts + loop send commit to each region in [](region,keys) parallelly + TiDB->>TiKV: commit(keys,commit_ts) + end + end + end + + TiDB-->>client: success +``` -1. 客户端开始一个事务。 +1. **客户端**开始一个事务。 - TiDB 从 PD 获取一个时间戳（单调递增且全局唯一），作为当前事务的唯一事务 ID，称为 `start_ts`。TiDB 实现了多版本并发控制，因此 `start_ts` 也作为该事务获取的数据库快照的版本。这意味着该事务只能读取 `start_ts` 时刻数据库中的数据。 + TiDB 从 PD 获取一个**时间戳**（单调递增且全局唯一），作为当前事务的唯一事务 ID，称为 `start_ts`。TiDB 实现了多版本并发控制，因此 `start_ts` 也作为该事务获取的数据库**快照**的版本。这意味着该事务只能读取 `start_ts` 时刻数据库中的数据。 -2. 客户端发起读请求。 +2. **客户端**发起**读请求**。 1. TiDB 从 PD 获取路由信息（数据在 TiKV 节点间的分布情况）。 2. TiDB 从 TiKV 获取 `start_ts` 版本的数据。 -3. 客户端发起写请求。 +3. **客户端**发起写请求。 - TiDB 检查写入的数据是否满足约束条件（确保数据类型正确、满足 NOT NULL 约束）。**合法数据会存储在 TiDB 中该事务的私有内存中**。 + TiDB 检查写入的数据是否满足**约束**（确保数据类型正确、NOT NULL 约束满足）。**有效数据会存储在 TiDB 中该事务的私有内存中**。 -4. 客户端发起提交请求。 +4. **客户端**发起提交请求。 -5. TiDB 开始两阶段提交，并在保证事务原子性的同时将数据持久化到存储中。 +5. TiDB 开始两阶段提交（2PC），并在存储中持久化数据，同时保证事务的原子性。 - 1. TiDB 从待写入的数据中选择一个主键（Primary Key）。 + 1. TiDB 从待写入的数据中选取一个主键（Primary Key）。 2. TiDB 从 PD 获取 Region 分布信息，并按 Region 对所有 key 进行分组。 - 3. TiDB 向所有涉及的 TiKV 节点发送 prewrite 请求。随后，TiKV 检查是否存在冲突或过期的版本。合法数据会被加锁。 + 3. TiDB 向所有涉及的 TiKV 节点发送 prewrite 请求。TiKV 检查是否有**冲突**或**过期**版本，有效数据会被加锁。 4. TiDB 收到 prewrite 阶段的所有响应，prewrite 成功。 - 5. TiDB 从 PD 获取一个提交版本号，标记为 `commit_ts`。 + 5. TiDB 从 PD 获取一个提交版本号，记为 `commit_ts`。 6. TiDB 向主键所在的 TiKV 节点发起第二次提交。TiKV 检查数据，并清理 prewrite 阶段遗留的锁。 7. TiDB 收到第二阶段成功完成的消息。 -6. TiDB 返回消息通知客户端事务已成功提交。 +6. TiDB 向**客户端**返回事务提交成功的消息。 7. TiDB 异步清理本次事务遗留的锁。 @@ -56,19 +105,19 @@ summary: 了解 TiDB 中的乐观事务模型。 * 基于单行事务实现跨节点事务 * 去中心化的锁管理 -但 TiDB 事务也存在以下缺点： +但 TiDB 事务也有以下缺点： -* 由于两阶段提交导致的事务延迟 +* 由于两阶段提交导致的事务延时 * 需要一个中心化的时间戳分配服务 -* 当内存中写入大量数据时，可能发生 OOM（内存溢出） +* 当内存中写入大量数据时可能发生 OOM（内存溢出） ## 事务重试 > **注意：** > -> 从 v8.0.0 开始，[`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) 系统变量已废弃，TiDB 不再支持乐观事务的自动重试。建议使用 [悲观事务模式](/pessimistic-transaction.md)。如果你遇到乐观事务冲突，可以在应用层捕获错误并重试事务。 +> 从 v8.0.0 版本开始，[`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) 系统变量已废弃，TiDB 不再支持乐观事务的自动重试。建议使用 [悲观事务模式](/pessimistic-transaction.md)。如果遇到乐观事务**冲突**，可以在应用程序中捕获错误并重试事务。 -在乐观事务模型下，在高并发争用场景中，事务可能因为写-写冲突而提交失败。从 v3.0.8 开始，TiDB 默认使用 [悲观事务模式](/pessimistic-transaction.md)，与 MySQL 一致。这意味着 TiDB 和 MySQL 在执行写类型 SQL 语句时会加锁，并且其可重复读隔离级别允许当前读，因此提交通常不会遇到异常。 +在乐观事务模型下，在高**并发**的**场景**中，事务可能因为写-写**冲突**而提交失败。从 v3.0.8 版本开始，TiDB 默认使用 [悲观事务模式](/pessimistic-transaction.md)，与 MySQL 一致。这意味着 TiDB 和 MySQL 在执行写类型 SQL 语句时会加锁，并且其可重复读（Repeatable Read）**隔离级别**允许当前读，因此提交通常不会遇到**异常**。 ### 自动重试 @@ -77,7 +126,7 @@ summary: 了解 TiDB 中的乐观事务模型。 > - 从 TiDB v3.0.0 开始，事务的自动重试默认关闭，因为它可能**破坏事务隔离级别**。 > - 从 TiDB v8.0.0 开始，不再支持乐观事务的自动重试。 -如果在事务提交时发生写-写冲突，TiDB 会自动重试包含写操作的 SQL 语句。你可以通过将 `tidb_disable_txn_auto_retry` 设置为 `OFF` 来开启自动重试，并通过配置 `tidb_retry_limit` 设置重试次数上限： +如果在事务提交过程中发生写-写**冲突**，TiDB 会自动重试包含写操作的 SQL 语句。你可以通过将 `tidb_disable_txn_auto_retry` 设置为 `OFF` 来开启自动重试，并通过配置 `tidb_retry_limit` 设置重试次数上限： ```toml # 是否禁用自动重试。（默认 "on"） @@ -87,7 +136,7 @@ tidb_disable_txn_auto_retry = OFF tidb_retry_limit = 10 ``` -你可以在会话级别或全局级别开启自动重试： +你可以在**会话级别**或**全局级别**开启自动重试： 1. 会话级别： @@ -115,27 +164,27 @@ tidb_retry_limit = 10 > **注意：** > -> `tidb_retry_limit` 变量决定了最大重试次数。当该变量设置为 `0` 时，所有事务都不会自动重试，包括自动提交的隐式单语句事务。这是完全禁用 TiDB 自动重试机制的方式。禁用自动重试后，所有冲突事务会以最快的方式向应用层报告失败（包括 `try again later` 消息）。 +> `tidb_retry_limit` 变量决定了最大重试次数。当该变量设置为 `0` 时，所有事务都不会自动重试，包括自动提交的隐式单语句事务。这是完全禁用 TiDB 自动重试机制的方法。禁用自动重试后，所有发生**冲突**的事务会以最快的方式向应用层报告失败（包括 `try again later` 消息）。 ### 重试的限制 -默认情况下，TiDB 不会重试事务，因为这可能导致更新丢失并破坏 [`REPEATABLE READ` 隔离级别](/transaction-isolation-levels.md)。 +默认情况下，TiDB 不会重试事务，因为这可能导致更新丢失并破坏 [`REPEATABLE READ` 隔离](/transaction-isolation-levels.md)。 原因可以从重试流程中看出： -1. 分配一个新的时间戳，标记为 `start_ts`。 +1. 分配一个新的时间戳，记为 `start_ts`。 2. 重试包含写操作的 SQL 语句。 3. 执行两阶段提交。 -在第 2 步，TiDB 只会重试包含写操作的 SQL 语句。然而，在重试时，TiDB 会收到一个新的版本号作为事务的起始时间。这意味着 TiDB 会在新的 `start_ts` 版本下重试 SQL 语句。在这种情况下，如果事务是基于其他查询结果进行数据更新，结果可能会不一致，因为违反了 `REPEATABLE READ` 隔离级别。 +在第 2 步中，TiDB 只会重试包含写操作的 SQL 语句。但在重试时，TiDB 会收到一个新的版本号作为事务的起始时间。这意味着 TiDB 会以新的 `start_ts` 版本的数据重试 SQL 语句。在这种情况下，如果事务根据其他**查询**结果进行数据**修改**，结果可能会不一致，因为违反了 `REPEATABLE READ` 隔离。 -如果你的应用可以容忍更新丢失，并且不需要 `REPEATABLE READ` 隔离级别的一致性，可以通过设置 `tidb_disable_txn_auto_retry = OFF` 启用该特性。 +如果你的应用可以**容忍**更新丢失，并且不要求 `REPEATABLE READ` 隔离**一致性**，可以通过设置 `tidb_disable_txn_auto_retry = OFF` 启用该功能。 ## 冲突检测 -作为分布式数据库，TiDB 在 TiKV 层进行内存冲突检测，主要发生在 prewrite 阶段。TiDB 实例是无状态的，彼此之间也不了解对方的存在，这意味着它们无法知道自己的写操作是否会在整个集群中产生冲突。因此，冲突检测是在 TiKV 层完成的。 +作为一款**分布式数据库**，TiDB 在 TiKV 层进行内存中的**冲突**检测，主要发生在 prewrite 阶段。TiDB **实例**是**无状态的**，彼此之间无法感知，因此无法知道自己的写操作是否会在整个**集群**中产生**冲突**。因此，**冲突**检测在 TiKV 层完成。 -相关配置如下： +配置如下： ```toml # 控制槽的数量。（默认 "2048000"） @@ -146,4 +195,4 @@ scheduler-concurrency = 2048000 ![Scheduler latch wait duration](/media/optimistic-transaction-metric.png) -当 `Scheduler latch wait duration` 较高且没有慢写入时，可以安全地判断此时存在大量写冲突。 \ No newline at end of file +当 `Scheduler latch wait duration` 较高且没有慢写入时，可以安全地判断此时存在大量写**冲突**。 \ No newline at end of file diff --git a/sql-statements/sql-statement-batch.md b/sql-statements/sql-statement-batch.md index 8afbf8df9dbac..86dcb1d6bfba8 100644 --- a/sql-statements/sql-statement-batch.md +++ b/sql-statements/sql-statement-batch.md @@ -1,25 +1,25 @@ --- title: BATCH -summary: 关于在 TiDB 数据库中使用 BATCH 的概述。 +summary: TiDB 数据库中 BATCH 的用法概述。 --- # BATCH -`BATCH` 语法在 TiDB 中将一个 DML 语句拆分成多个语句以供执行。这意味着 **没有保证**事务的原子性和隔离性。因此，它是一个“非事务性”语句。 +`BATCH` 语法会将一个 DML 语句在 TiDB 中切分为多个语句进行执行。这意味着 **不保证** 事务的原子性和隔离性。因此，它是一个“非事务型”语句。 -目前，`INSERT`、`REPLACE`、`UPDATE` 和 `DELETE` 支持在 `BATCH` 中使用。 +目前，`BATCH` 支持 `INSERT`、`REPLACE`、`UPDATE` 和 `DELETE`。 -基于某一列，`BATCH` 语法将一个 DML 语句划分为多个范围进行执行。在每个范围内，执行单个 SQL 语句。 +基于某一列，`BATCH` 语法将 DML 语句切分为多个作用域范围进行执行。在每个范围内，会执行一条 SQL 语句。 -有关用法和限制的详细信息，请参见 [Non-transactional DML statements](/non-transactional-dml.md)。 +关于用法和限制的详细信息，参见 [非事务型 DML 语句](/non-transactional-dml.md)。 -当你在 `BATCH` 语句中使用多表连接时，需要指定列的完整路径以避免歧义： +当你在 `BATCH` 语句中使用多表 join 时，需要指定列的完整路径以避免歧义： ```sql BATCH ON test.t2.id LIMIT 1 INSERT INTO t SELECT t2.id, t2.v, t3.v FROM t2 JOIN t3 ON t2.k = t3.k; ``` -上述语句将要拆分的列指定为 `test.t2.id`，这是明确的。如果你使用如下的 `id`，则会报错： +上述语句指定了切分的列为 `test.t2.id`，这样不会产生歧义。如果你像下面这样仅使用 `id`，则会报错： ```sql BATCH ON id LIMIT 1 INSERT INTO t SELECT t2.id, t2.v, t3.v FROM t2 JOIN t3 ON t2.k = t3.k; @@ -27,7 +27,11 @@ BATCH ON id LIMIT 1 INSERT INTO t SELECT t2.id, t2.v, t3.v FROM t2 JOIN t3 ON t2 Non-transactional DML, shard column must be fully specified ``` -## 概要 +> **注意：** +> +> `BATCH` 语句在内部会被重写并切分为多个 DML 语句进行执行。在当前版本中，表别名可能不会被保留，这可能导致 `where 子句` 中出现 `Unknown column '.'` 的错误。为避免此问题，请不要使用表别名。在执行前，可以使用 `DRY RUN QUERY` 或 `DRY RUN` 预览切分后的语句。更多信息参见 [非事务型 DML 语句](/non-transactional-dml.md)。 + +## 语法 ```ebnf+diagram NonTransactionalDMLStmt ::= @@ -45,8 +49,8 @@ ShardableStmt ::= ## MySQL 兼容性 -`BATCH` 语法是 TiDB 特有的，不兼容 MySQL。 +`BATCH` 语法是 TiDB 特有的，并不兼容 MySQL。 -## 另请参见 +## 另请参阅 -* [Non-transactional DML statements](/non-transactional-dml.md) \ No newline at end of file +* [非事务型 DML 语句](/non-transactional-dml.md) diff --git a/subquery-optimization.md b/subquery-optimization.md index 8b0001287ede6..b3ec55b0a61ce 100644 --- a/subquery-optimization.md +++ b/subquery-optimization.md @@ -5,44 +5,45 @@ summary: 了解与子查询相关的优化。 # 子查询相关优化 -本文主要介绍与子查询相关的优化。 +本文主要介绍子查询相关的优化。 子查询通常出现在以下几种情况： +- `... / ALL (SELECT ... FROM ...)` - `NOT IN (SELECT ... FROM ...)` -- `NOT EXISTS (SELECT ... FROM ...)` - `IN (SELECT ... FROM ..)` +- `NOT EXISTS (SELECT ... FROM ...)` - `EXISTS (SELECT ... FROM ...)` - `... >/>=/ ANY (SELECT ... FROM ...)` -在这种情况下，`ALL` 和 `ANY` 可以分别用 `MAX` 和 `MIN` 替换。当表为空时，`MAX(EXPR)` 和 `MIN(EXPR)` 的结果为 NULL。当 `EXPR` 的结果包含 `NULL` 时，表现也是一样的。`EXPR` 的结果是否包含 `NULL` 可能会影响表达式的最终结果，因此完整的重写形式如下： +在这种情况下，`ALL` 和 `ANY` 可以分别用 `MAX` 和 `MIN` 替换。当表为空时，`MAX(EXPR)` 和 `MIN(EXPR)` 的结果为空值。当 `EXPR` 的结果包含空值时，行为也是一样的。`EXPR` 的结果是否包含空值可能会影响表达式的最终结果，因此完整的重写形式如下： -- `t.id < all (select s.id from s)` 会被重写为 `t.id < min(s.id) and if(sum(s.id is null) != 0, null, true)` -- `t.id > any (select s.id from s)` 会被重写为 `t.id > max(s.id) or if(sum(s.id is null) != 0, null, false)` +- `t.id < all (select s.id from s)` 被重写为 `t.id < min(s.id) and if(sum(s.id is null) != 0, null, true)` +- `t.id > any (select s.id from s)` 被重写为 `t.id > max(s.id) or if(sum(s.id is null) != 0, null, false)` ## `... != ANY (SELECT ... FROM ...)` -在这种情况下，如果子查询中的所有值都是不同的，只需与这些值进行比较即可。如果子查询中不同值的数量大于 1，则必然存在不等。因此，这类子查询可以重写为： +在这种情况下，如果子查询中的所有值都是不同的，只需与它们进行比较即可。如果子查询中不同值的数量大于 1，则必然存在不等。因此，这类子查询可以重写为： -- `select * from t where t.id != any (select s.id from s)` 会被重写为 `select t.* from t, (select s.id, count(distinct s.id) as cnt_distinct from s) where (t.id != s.id or cnt_distinct > 1)` +- `select * from t where t.id != any (select s.id from s)` 被重写为 `select t.* from t, (select s.id, count(distinct s.id) as cnt_distinct from s) where (t.id != s.id or cnt_distinct > 1)` ## `... = ALL (SELECT ... FROM ...)` -在这种情况下，如果子查询中不同值的数量大于 1，则该表达式的结果必然为 false。因此，这类子查询在 TiDB 中会被重写为： +在这种情况下，如果子查询中不同值的数量大于 1，则该表达式的结果必然为 false。因此，TiDB 会将此类子查询重写为如下形式： -- `select * from t where t.id = all (select s.id from s)` 会被重写为 `select t.* from t, (select s.id, count(distinct s.id) as cnt_distinct from s ) where (t.id = s.id and cnt_distinct <= 1)` +- `select * from t where t.id = all (select s.id from s)` 被重写为 `select t.* from t, (select s.id, count(distinct s.id) as cnt_distinct from s ) where (t.id = s.id and cnt_distinct <= 1)` ## `... IN (SELECT ... FROM ...)` -在这种情况下，`IN` 的子查询会被重写为 `SELECT ... FROM ... GROUP ...`，然后再重写为常规的 `JOIN` 形式。 +在这种情况下，`IN` 的子查询会被重写为 `SELECT ... FROM ... GROUP ...`，然后再重写为普通的 `JOIN` 形式。 -例如，`select * from t1 where t1.a in (select t2.a from t2)` 会被重写为 `select t1.* from t1, (select distinct(a) a from t2) t2 where t1.a = t2. The form of a`。这里的 `DISTINCT` 属性如果 `t2.a` 拥有 `UNIQUE` 属性，则可以自动消除。 +例如，`select * from t1 where t1.a in (select t2.a from t2)` 被重写为 `select t1.* from t1, (select distinct(a) a from t2) t2 where t1.a = t2.a`。如果 `t2.a` 拥有 `UNIQUE` 属性，这里的 `DISTINCT` 属性可以被自动消除。 ```sql explain select * from t1 where t1.a in (select t2.a from t2); @@ -61,11 +62,11 @@ explain select * from t1 where t1.a in (select t2.a from t2); +------------------------------+---------+-----------+------------------------+----------------------------------------------------------------------------+ ``` -当 `IN` 子查询相对较小而外部查询较大时，这种重写可以获得更好的性能，因为如果不进行重写，无法使用 t2 作为驱动表的 `index join`。但缺点是当重写过程中无法自动消除聚合且 `t2` 表较大时，这种重写会影响查询性能。目前，可以通过变量 [tidb\_opt\_insubq\_to\_join\_and\_agg](/system-variables.md#tidb_opt_insubq_to_join_and_agg) 控制该优化。当该优化不适用时，你可以手动关闭它。 +当 `IN` 子查询相对较小而外部查询较大时，这种重写可以获得更好的性能，因为如果不进行重写，无法使用以 t2 作为驱动表的索引连接。但缺点是当重写过程中聚合无法被自动消除且 `t2` 表较大时，这种重写会影响查询性能。目前通过变量 [tidb\_opt\_insubq\_to\_join\_and\_agg](/system-variables.md#tidb_opt_insubq_to_join_and_agg) 控制该优化。当该优化不适用时，你可以手动关闭。 ## `EXISTS` 子查询与 `... >/>=/ {SQL type}：每秒由不同 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE`）语句消耗的数据库时间。 | -| Query Per Second | {SQL type} | 所有 TiDB 实例每秒执行的 SQL 语句数量，按 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE`）分类统计。 | -| Query Duration | avg-{SQL type}, 99-{SQL type} | 从客户端发送请求到 TiDB，直到 TiDB 执行请求并将结果返回给客户端的持续时间。通常，客户端请求以 SQL 语句形式发送；但该持续时间也可能包含如 `COM_PING`、`COM_SLEEP`、`COM_STMT_FETCH`、`COM_SEND_LONG_DATA` 等命令的执行时间。TiDB 支持 Multi-Query，即客户端可一次发送多个 SQL 语句，如 `select 1; select 1; select 1;`。此时，该查询的总执行时间包含所有 SQL 语句的执行时间。 | -| Failed Queries | All, {Error type} @ {instance} | 按每个 TiDB 实例每分钟 SQL 语句执行错误的错误类型（如语法错误、主键冲突）进行统计。包含发生错误的模块及错误码。 | +| Database Time by SQL types | database time, {SQL type} | database time：每秒的总数据库时间。
{SQL type}：每秒由 SQL 语句消耗的数据库时间，按 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE` 等）收集。 | +| Query Per Second | {SQL type} | 所有 TiDB 实例每秒执行的 SQL 语句数量，按 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE` 等）收集。 | +| Query Duration | avg-{SQL type}, 99-{SQL type} | 从客户端发送请求到 TiDB，直到 TiDB 执行请求并将结果返回给客户端的持续时间。通常，客户端请求以 SQL 语句形式发送；但该持续时间也可能包含如 `COM_PING`、`COM_SLEEP`、`COM_STMT_FETCH`、`COM_SEND_LONG_DATA` 等命令的执行时间。TiDB 支持 Multi-Query，即客户端可一次发送多条 SQL 语句，如 `select 1; select 1; select 1;`。此时，该查询的总执行时间包含所有 SQL 语句的执行时间。 | +| Failed Queries | All, {Error type} @ {instance} | 按每个 TiDB 实例每分钟 SQL 语句执行错误统计错误类型（如语法错误、主键冲突等）。包含发生错误的模块及错误码。 | | Command Per Second | Query, StmtExecute, and StmtPrepare | 所有 TiDB 实例每秒按命令类型处理的命令数量。 | | Queries Using Plan Cache OPS | hit, miss | hit：所有 TiDB 实例每秒使用计划缓存的查询数量。
miss：所有 TiDB 实例每秒未命中计划缓存的查询数量。 | | Transaction Per Second | {types}-{transaction model} | 每秒执行的事务数量。 | @@ -47,19 +47,19 @@ TiDB Cloud 会在 **统计/指标（信息）** 页面收集并展示你的集 | 统计/指标（信息）名称 | 标签 | 描述 | | :------------| :------| :-------------------------------------------- | | Average Idle Connection Duration | avg-in-txn, avg-not-in-txn | 连接空闲持续时间表示连接处于空闲状态的时长。
avg-in-txn：连接处于事务中时的平均空闲持续时间。
avg-not-in-txn：连接不在事务中时的平均空闲持续时间。 | -| Get Token Duration | avg, 99 | 获取 SQL 语句 token 的平均或第 99 百分位耗时。 | -| Parse Duration | avg, 99 | 解析 SQL 语句的平均或第 99 百分位耗时。 | -| Compile Duration | avg, 99 | 将解析后的 SQL AST 编译为执行计划的平均或第 99 百分位耗时。 | -| Execute Duration | avg, 99 | 执行 SQL 语句执行计划的平均或第 99 百分位耗时。 | -| Average TiDB KV Request Duration | {Request Type} | 所有 TiDB 实例按请求类型（如 `Get`、`Prewrite`、`Commit`）执行 KV 请求的平均耗时。 | -| Average TiKV gRPC Duration | {Request Type} | 所有 TiKV 实例按请求类型（如 `kv_get`、`kv_prewrite`、`kv_commit`）执行 gRPC 请求的平均耗时。 | -| Average / P99 PD TSO Wait/RPC Duration | wait-avg/99, rpc-avg/99 | Wait：所有 TiDB 实例等待 PD 返回 TSO 的平均或第 99 百分位耗时。
RPC：所有 TiDB 实例从发送 TSO 请求到 PD 到收到 TSO 的平均或第 99 百分位耗时。 | -| Average / P99 Storage Async Write Duration | avg, 99 | 异步写入的平均或第 99 百分位耗时。平均存储异步写入耗时 = 平均 store 耗时 + 平均 apply 耗时。 | -| Average / P99 Store Duration | avg, 99 | 异步写入过程中存储循环的平均或第 99 百分位耗时。 | -| Average / P99 Apply Duration | avg, 99 | 异步写入过程中 apply 循环的平均或第 99 百分位耗时。 | -| Average / P99 Append Log Duration | avg, 99 | Raft 追加日志的平均或第 99 百分位耗时。 | -| Average / P99 Commit Log Duration | avg, 99 | Raft 提交日志的平均或第 99 百分位耗时。 | -| Average / P99 Apply Log Duration | avg, 99 | Raft 应用日志的平均或第 99 百分位耗时。 | +| Get Token Duration | avg, 99 | 获取 SQL 语句 token 的平均或第 99 百分位持续时间。 | +| Parse Duration | avg, 99 | 解析 SQL 语句的平均或第 99 百分位持续时间。 | +| Compile Duration | avg, 99 | 将解析后的 SQL AST 编译为执行计划的平均或第 99 百分位持续时间。 | +| Execute Duration | avg, 99 | 执行 SQL 语句执行计划的平均或第 99 百分位持续时间。 | +| Average TiDB KV Request Duration | {Request Type} | 所有 TiDB 实例按请求类型（如 `Get`、`Prewrite`、`Commit` 等）执行 KV 请求的平均耗时。 | +| Average TiKV gRPC Duration | {Request Type} | 所有 TiKV 实例按请求类型（如 `kv_get`、`kv_prewrite`、`kv_commit` 等）执行 gRPC 请求的平均耗时。 | +| Average / P99 PD TSO Wait/RPC Duration | wait-avg/99, rpc-avg/99 | Wait：所有 TiDB 实例等待 PD 返回 TSO 的平均或第 99 百分位持续时间。
RPC：所有 TiDB 实例从发送 TSO 请求到 PD 到收到 TSO 的平均或第 99 百分位持续时间。 | +| Average / P99 Storage Async Write Duration | avg, 99 | 异步写入的平均或第 99 百分位持续时间。平均存储异步写入持续时间 = 平均 store 持续时间 + 平均 apply 持续时间。 | +| Average / P99 Store Duration | avg, 99 | 异步写入过程中存储循环的平均或第 99 百分位持续时间。 | +| Average / P99 Apply Duration | avg, 99 | 异步写入过程中 apply 循环的平均或第 99 百分位持续时间。 | +| Average / P99 Append Log Duration | avg, 99 | Raft 追加日志的平均或第 99 百分位持续时间。 | +| Average / P99 Commit Log Duration | avg, 99 | Raft 提交日志的平均或第 99 百分位持续时间。 | +| Average / P99 Apply Log Duration | avg, 99 | Raft 应用日志的平均或第 99 百分位持续时间。 | | Affected Rows | {SQL type} | 按 SQL 类型每秒处理的行数。 | | Leader Count | {instance} | TiKV 节点承载的 Raft Leader Region 数量。 | | Region Count | {instance} | TiKV 节点管理的总数据 Region 数量。 | @@ -68,19 +68,19 @@ TiDB Cloud 会在 **统计/指标（信息）** 页面收集并展示你的集 | 统计/指标（信息）名称 | 标签 | 描述 | | :------------| :------| :-------------------------------------------- | -| TiDB Uptime | node | 每个 TiDB 节点自上次重启以来的运行时长。 | +| TiDB Uptime | node | 每个 TiDB 节点自上次重启以来的运行时。 | | TiDB CPU Usage | node, limit | 每个 TiDB 节点的 CPU 使用率统计或上限。 | | TiDB Memory Usage | node, limit | 每个 TiDB 节点的内存使用率统计或上限。 | -| TiKV Uptime | node | 每个 TiKV 节点自上次重启以来的运行时长。 | +| TiKV Uptime | node | 每个 TiKV 节点自上次重启以来的运行时。 | | TiKV CPU Usage | node, limit | 每个 TiKV 节点的 CPU 使用率统计或上限。 | | TiKV Memory Usage | node, limit | 每个 TiKV 节点的内存使用率统计或上限。 | | TiKV IO Bps | node-write, node-read | 每个 TiKV 节点每秒读写的总输入/输出字节数。 | -| TiKV Storage Usage | node, limit | 每个 TiKV 节点的存储使用率统计或上限。 | -| TiFlash Uptime | node | 每个 TiFlash 节点自上次重启以来的运行时长。 | +| TiKV Storage Usage | node, limit | 每个 TiKV 节点的存储使用率统计或上限。存储使用量包括存储引擎中的逻辑数据大小，以及 WAL 文件和临时文件。 | +| TiFlash Uptime | node | 每个 TiFlash 节点自上次重启以来的运行时。 | | TiFlash CPU Usage | node, limit | 每个 TiFlash 节点的 CPU 使用率统计或上限。 | | TiFlash Memory Usage | node, limit | 每个 TiFlash 节点的内存使用率统计或上限。 | | TiFlash IO MBps | node-write, node-read | 每个 TiFlash 节点的读写总字节数。 | -| TiFlash Storage Usage | node, limit | 每个 TiFlash 节点的存储使用率统计或上限。 | +| TiFlash Storage Usage | node, limit | 每个 TiFlash 节点的存储使用率统计或上限。存储使用量包括存储引擎中的逻辑数据大小，以及 WAL 文件和临时文件。 | | TiProxy CPU Usage | node | 每个 TiProxy 节点的 CPU 使用率统计。上限为 100%。 | | TiProxy Connections | node | 每个 TiProxy 节点的连接数。 | | TiProxy Throughput | node | 每个 TiProxy 节点每秒传输的字节数。 | @@ -88,7 +88,7 @@ TiDB Cloud 会在 **统计/指标（信息）** 页面收集并展示你的集 ## TiDB Cloud Starter 和 TiDB Cloud Essential 集群的统计/指标（信息） -**统计/指标（信息）** 页面为 TiDB Cloud Starter 和 TiDB Cloud Essential 集群提供了两个标签页： +**Metrics** 页面为 TiDB Cloud Starter 和 TiDB Cloud Essential 集群提供了两个统计/指标（信息）标签页： - **Cluster Status**：展示集群级别的主要统计/指标（信息）。 - **Database Status**：展示数据库级别的主要统计/指标（信息）。 @@ -99,15 +99,15 @@ TiDB Cloud 会在 **统计/指标（信息）** 页面收集并展示你的集 | 统计/指标（信息）名称 | 标签 | 描述 | | :------------| :------| :-------------------------------------------- | -| Request Units | RU per second | Request Unit（RU）是用于跟踪 TiDB Cloud Starter 集群中查询或事务资源消耗的度量单位。除用户查询外，后台活动也会消耗 RU，因此即使 QPS 为 0，每秒 RU 使用量也可能不为零。| -| Capacity vs Usage (RU/s) | Provisioned capacity (RCU), Consumed RU/s | TiDB Cloud Essential 集群中配置的 Request Capacity Units（RCU）和每秒消耗的 Request Units（RU）。 | +| Request Units | RU per second | Request Unit（RU）是用于跟踪 TiDB Cloud Starter 集群中查询或事务资源消耗的度量单位。除用户查询外，后台活动也会消耗 RU，因此即使 QPS 为 0，每秒 RU 使用量也可能大于 0。| +| Capacity vs Usage (RU/s) | Provisioned capacity (RCU), Consumed RU/s | TiDB Cloud Essential 集群中每秒的 Request Capacity Units（RCU）和已消耗的 Request Units（RU）。 | | Used Storage Size | Row-based storage, Columnar storage | 行存储和列存储的大小。仅当每种存储类型达到 50 MiB 或更大时才显示该统计/指标（信息）。 | -| Query Per Second | All, {SQL type} | 每秒执行的 SQL 语句数量，按 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE`）分类统计。 | +| Query Per Second | All, {SQL type} | 每秒执行的 SQL 语句数量，按 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE` 等）收集。 | | Query Duration | Avg, P99, P99-{SQL type} | 从客户端发送请求到 TiDB Cloud Starter 或 TiDB Cloud Essential 集群，直到集群执行请求并将结果返回给客户端的持续时间。 | | Failed Query | All | 每秒 SQL 语句执行错误的数量。 | | Transaction Per Second | All | 每秒执行的事务数量。 | | Transaction Duration | Avg, P99 | 事务的执行持续时间。 | -| Lock-wait | P95, P99 | 事务等待获取悲观锁所花费的时间。较高的值表示在同一行或键上存在竞争。 | +| Lock-wait | P95, P99 | 事务等待获取悲观锁所花费的时间。高值通常表示对同一行或键的竞争。 | | Total Connection | All | 连接到 TiDB Cloud Starter 或 TiDB Cloud Essential 集群的连接数。 | | Idle Connection Duration | P99, P99(in-txn), P99(not-in-txn) | 连接在开启事务时保持空闲的时间。较长的持续时间通常表示应用逻辑较慢或存在长事务。 | @@ -117,23 +117,23 @@ TiDB Cloud 会在 **统计/指标（信息）** 页面收集并展示你的集 | 统计/指标（信息）名称 | 标签 | 描述 | | :------------| :------| :-------------------------------------------- | -| QPS Per DB | All, {Database name} | 每个数据库每秒执行的 SQL 语句数量，按 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE`）分类统计。 | -| Average Query Duration Per DB | All, {Database name} | 从客户端发送请求到某数据库，直到该数据库执行请求并将结果返回给客户端的持续时间。| -| Failed Query Per DB | All, {Database name} | 每个数据库每秒 SQL 语句执行错误的错误类型统计。| +| QPS Per DB | All, {Database name} | 每个数据库每秒执行的 SQL 语句数量，按 SQL 类型（如 `SELECT`、`INSERT`、`UPDATE` 等）收集。 | +| Average Query Duration Per DB | All, {Database name} | 从客户端发送请求到数据库，直到数据库执行请求并将结果返回给客户端的持续时间。| +| Failed Query Per DB | All, {Database name} | 每个数据库每秒 SQL 语句执行错误的类型统计。| ## 常见问题 -**1. 为什么本页面的某些面板为空？** +**1. 为什么本页面有些面板为空？** -如果某个面板没有提供任何统计/指标（信息），可能的原因如下： +如果某个面板没有提供任何统计/指标（信息），可能原因如下： -- 对应集群的负载未触发该统计/指标（信息）。例如，在没有失败查询的情况下，失败查询统计/指标（信息）始终为空。 +- 对应集群的负载未触发该统计/指标（信息）。例如，如果没有失败查询，则失败查询统计/指标（信息）始终为空。 - 集群版本较低。你需要将其升级到最新的 TiDB 版本以查看这些统计/指标（信息）。 -如果排除了上述所有原因，你可以联系 [PingCAP 支持团队](/tidb-cloud/tidb-cloud-support.md) 进行排查。 +如果排除了上述所有原因，你可以联系 [PingCAP support team](/tidb-cloud/tidb-cloud-support.md) 进行排查。 **2. 为什么在极少数情况下统计/指标（信息）可能出现不连续？** 在极少数情况下，统计/指标（信息）可能会丢失，例如统计/指标（信息）系统压力过大时。 -如果你遇到此问题，可以联系 [PingCAP 支持](/tidb-cloud/tidb-cloud-support.md) 进行排查。 \ No newline at end of file +如果你遇到此问题，可以联系 [PingCAP Support](/tidb-cloud/tidb-cloud-support.md) 进行排查。 \ 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 4356d8327c5d5..27e6a558e7e13 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -1,11 +1,11 @@ --- title: Sink to Cloud Storage -summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式同步到 Amazon S3、Google Cloud Storage (GCS) 或 Azure Blob Storage。内容包括限制、目标端配置、同步及规范配置，以及启动同步流程。 +summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式同步到 Amazon S3、Google Cloud Storage (GCS) 或 Azure Blob Storage。内容包括限制、目标端配置、同步与规范配置，以及启动同步流程。 --- # Sink to Cloud Storage -本文档描述如何创建 changefeed，将数据从 TiDB Cloud 流式同步到云存储。目前支持 Amazon S3、Google Cloud Storage (GCS) 和 Azure Blob Storage。 +本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式同步到云存储。目前支持 Amazon S3、Google Cloud Storage (GCS) 和 Azure Blob Storage。 > **注意：** > @@ -16,37 +16,69 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式 - 每个 TiDB Cloud 集群最多可创建 100 个 changefeed。 - 由于 TiDB Cloud 使用 TiCDC 建立 changefeed，因此具有与 [TiCDC 相同的限制](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)。 -- 如果待同步的表没有主键或非空唯一索引，则在同步过程中由于缺乏唯一约束，在某些重试场景下可能会导致下游插入重复数据。 +- 如果待同步的表没有主键或非空唯一索引，则在某些重试场景下，由于同步过程中缺乏唯一约束，可能会导致下游插入重复数据。 ## 步骤 1. 配置目标端 -进入目标 TiDB 集群的集群总览页面。在左侧导航栏点击 **Data** > **Changefeed**，点击 **Create Changefeed**，并选择 **Amazon S3**、**GCS** 或 **Azure Blob Storage** 作为目标端。具体配置流程根据所选目标端不同而有所区别。 +进入目标 TiDB 集群的集群总览页面。在左侧导航栏点击 **Data** > **Changefeed**，点击 **Create Changefeed** 进入 **Destination** 页面，然后根据集群所在云服务商选择 **Amazon S3**、**GCS** 或 **Azure Blob Storage** 作为目标端。不同目标端的配置流程有所不同。
-对于 **Amazon S3**，填写 **S3 Endpoint** 区域：`S3 URI`、`Access Key ID` 和 `Secret Access Key`。请确保 S3 bucket 与 TiDB 集群处于同一区域。 +对于 **Amazon S3**，你可以选择使用 **AWS Role ARN** 或 **AWS access key** 进行认证。推荐使用 **AWS Role ARN**，以获得更强的安全性和更便捷的管理。 -![s3_endpoint](/media/tidb-cloud/changefeed/sink-to-cloud-storage-s3-endpoint.jpg) +**选项 1：AWS Role ARN（推荐）** + +如需使用 IAM Role 进行认证，请按以下步骤操作： + +1. 在 Amazon S3 的 **Destination** 页面，填写 **S3 URI**。确保 S3 bucket 与 TiDB 集群处于同一 AWS 区域。 +2. 在 **Bucket Access** 下选择 **AWS Role ARN**。 +3. 若需创建新的 Role ARN，点击 **Click here to create new one with AWS CloudFormation**。该模板会自动配置所需权限。 + + 如果你希望手动创建角色，请点击 **Create Role ARN manually** 查看 TiDB Cloud 账户信息及所需策略。 + +4. 确保你的 IAM 角色对目标 bucket 至少拥有以下权限： + + - `s3:ListBucket` + - `s3:PutObject` + - `s3:GetObject` + - `s3:DeleteObject` + +5. 将生成的 **Role ARN** 粘贴到对应输入框。 + +**选项 2：AWS access key** + +> **注意：** +> +> 使用 access key 和 secret key（AK/SK）需要手动管理和轮转凭证，存在更高的安全风险。为提升安全性，建议优先使用 **AWS Role ARN**。 + +如需使用 access key 认证，请按以下步骤操作： + +1. 在 Amazon S3 的 **Destination** 页面，填写 **S3 URI**。确保 S3 bucket 与 TiDB 集群处于同一 AWS 区域。 +2. 在 **Bucket Access** 下选择 **AWS Access Key**。 +3. 填写以下内容： + + - **Access Key ID** + - **Secret Access Key**
-对于 **GCS**，在填写 **GCS Endpoint** 之前，需要先授予 GCS bucket 访问权限。请按照以下步骤操作： +对于 **GCS**，在填写 **GCS Endpoint** 前，需要先授予 GCS bucket 访问权限。请按以下步骤操作： -1. 在 TiDB Cloud 控制台，记录下 **Service Account ID**，该 ID 用于授予 TiDB Cloud 访问你的 GCS bucket 的权限。 +1. 在 TiDB Cloud 控制台记录 **Service Account ID**，用于授权 TiDB Cloud 访问你的 GCS bucket。 ![gcs_endpoint](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-endpoint.png) -2. 在 Google Cloud 控制台，为你的 GCS bucket 创建一个 IAM 角色。 +2. 在 Google Cloud 控制台为你的 GCS bucket 创建 IAM 角色。 1. 登录 [Google Cloud 控制台](https://console.cloud.google.com/)。 - 2. 进入 [Roles](https://console.cloud.google.com/iam-admin/roles) 页面，然后点击 **Create role**。 + 2. 进入 [Roles](https://console.cloud.google.com/iam-admin/roles) 页面，点击 **Create role**。 ![Create a role](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-create-role.png) - 3. 输入角色的名称、描述、ID 及角色发布阶段。角色名称创建后不可更改。 - 4. 点击 **Add permissions**，为该角色添加以下权限，然后点击 **Add**。 + 3. 输入角色名称、描述、ID 及角色发布阶段。角色创建后名称不可更改。 + 4. 点击 **Add permissions**，为角色添加以下权限，然后点击 **Add**。 - storage.buckets.get - storage.objects.create @@ -57,69 +89,69 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式 ![Add permissions](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-assign-permission.png) -3. 进入 [Bucket](https://console.cloud.google.com/storage/browser) 页面，选择你希望 TiDB Cloud 访问的 GCS bucket。请注意，GCS bucket 必须与 TiDB 集群处于同一区域。 +3. 进入 [Bucket](https://console.cloud.google.com/storage/browser) 页面，选择你希望 TiDB Cloud 访问的 GCS bucket。注意，GCS bucket 必须与 TiDB 集群处于同一区域。 4. 在 **Bucket details** 页面，点击 **Permissions** 标签页，然后点击 **Grant access**。 ![Grant Access to the bucket ](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-grant-access-1.png) -5. 填写以下信息以授予 bucket 访问权限，然后点击 **Save**。 +5. 填写以下信息以授权 bucket 访问权限，然后点击 **Save**。 - - 在 **New Principals** 字段中，粘贴之前记录的目标 TiDB 集群的 **Service Account ID**。 + - 在 **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** 字段。 +7. 回到 TiDB Cloud 控制台，在 Changefeed 的 **Destination** 页面，填写 **bucket gsutil URI** 字段。
-对于 **Azure Blob Storage**，你需要先在 Azure 门户配置容器并获取 SAS token。请按照以下步骤操作： +对于 **Azure Blob Storage**，你需要先在 Azure 门户配置容器并获取 SAS token。请按以下步骤操作： -1. 在 [Azure 门户](https://portal.azure.com/) 创建一个用于存储 changefeed 数据的容器。 +1. 在 [Azure 门户](https://portal.azure.com/) 创建用于存储 changefeed 数据的容器。 - 1. 在左侧导航栏点击 **Storage Accounts**，然后选择你的存储账户。 + 1. 在左侧导航栏点击 **Storage Accounts**，选择你的存储账户。 2. 在存储账户导航菜单中，选择 **Data storage** > **Containers**，然后点击 **+ Container**。 - 3. 输入新容器的名称，设置匿名访问级别（推荐级别为 **Private**），然后点击 **Create**。 + 3. 输入新容器名称，设置匿名访问级别（推荐选择 **Private**），然后点击 **Create**。 2. 获取目标容器的 URL。 1. 在容器列表中，选择你的目标容器。 - 2. 点击容器的 **...**，然后选择 **Container properties**。 - 3. 保存 **URL** 值以备后用，例如 `https://.blob.core.windows.net/`。 + 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 指定一个足够长的有效期，以满足你的需求。 + 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 无法回收，因此请谨慎设置其有效期。 + > - changefeed 会持续写入事件，请确保 SAS token 有足够长的有效期。为安全起见，建议每 6 到 12 个月更换一次 token。 + > - 生成的 SAS token 无法回收，因此请谨慎设置有效期。 > - 为保证持续可用性，请在 SAS token 过期前重新生成并更新 token。 - 6. 点击 **Generate SAS and connection string**，然后保存 **SAS 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** 页面，填写以下字段： +4. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入 Changefeed 的 **Destination** 页面，填写以下内容： - **Blob URL**：输入第 2 步获取的容器 URL，可选添加前缀。 - **SAS Token**：输入第 3 步获取的 SAS token。 @@ -130,7 +162,7 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式 点击 **Next**，建立 TiDB Cloud Dedicated 集群与 Amazon S3、GCS 或 Azure Blob Storage 的连接。TiDB Cloud 会自动测试并验证连接是否成功。 - 若连接成功，将进入下一步配置。 -- 若连接失败，会显示连接错误，你需要处理该错误。错误解决后，点击 **Next** 重新尝试连接。 +- 若连接失败，会显示连接错误，你需要处理该错误。错误解决后，点击 **Next** 重试连接。 ## 步骤 2. 配置同步 @@ -138,16 +170,16 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式 ![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 规则中数据库和表名的匹配是否大小写敏感。默认情况下，匹配不区分大小写。 + - **Filter Rules**：你可以在此列设置 filter 规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则后，TiDB Cloud 会查询 TiDB 中所有表，并仅在右侧框中显示符合规则的表。最多可添加 100 条 filter 规则。 - **Tables with valid keys**：此列显示具有有效键（包括主键或唯一索引）的表。 - - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步时存在挑战，因为缺乏唯一标识符，在处理下游重复事件时可能导致数据不一致。为保证数据一致性，建议在启动同步前为这些表添加唯一键或主键，或通过过滤规则排除这些表。例如，可通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 + - **Tables without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步时存在挑战，因为缺乏唯一标识符，处理下游重复事件时可能导致数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或通过 filter 规则排除这些表。例如，可通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 2. 自定义 **Event Filter**，筛选你希望同步的事件。 - - **Tables matching**：你可以在此列设置事件过滤器将应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个 changefeed 最多可添加 10 条事件过滤规则。 - - **Event Filter**：你可以使用以下事件过滤器，从 changefeed 中排除特定事件： - - **Ignore event**：排除指定类型的事件。 + - **Tables matching**：你可以在此列设置 event filter 应用于哪些表。规则语法与前述 **Table Filter** 区域相同。每个 changefeed 最多可添加 10 条 event filter 规则。 + - **Event Filter**：你可以使用以下事件过滤器排除特定事件类型： + - **Ignore event**：排除指定事件类型。 - **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` 的更新。 @@ -158,26 +190,26 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式 - 从现在开始同步 - 从指定的 [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**：按年、月、日轮转数据，或选择不轮转。 - **Delimiter**：指定 CSV 文件中用于分隔值的字符。逗号（`,`）是最常用的分隔符。 - **Quote**：指定用于包裹包含分隔符或特殊字符的值的字符。通常使用双引号（`"`）作为引用字符。 - - **Null/Empty Values**：指定在 CSV 文件中如何表示空值或空字符串。这对于正确处理和解析数据非常重要。 + - **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)。 @@ -194,24 +226,24 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud 流式 > **注意：** > - > 这两个参数会影响每个数据库表在云存储中生成的对象数量。如果表数量较多，使用相同配置会增加生成对象的数量，并提升调用云存储 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. 配置规范 -点击 **Next**，配置 changefeed 规范。 +点击 **Next** 配置 changefeed 规范。 -1. 在 **Changefeed Specification** 区域，指定 changefeed 使用的 Replication Capacity Units (RCUs) 数量。 -2. 在 **Changefeed Name** 区域，指定 changefeed 的名称。 +1. 在 **Changefeed Specification** 区域，指定 changefeed 使用的 Replication Capacity Units（RCU）数量。 +2. 在 **Changefeed Name** 区域，为 changefeed 指定名称。 ## 步骤 4. 审核配置并启动同步 -点击 **Next**，审核 changefeed 配置。 +点击 **Next** 审核 changefeed 配置。 -- 如果你已确认所有配置无误，点击 **Create** 以创建 changefeed。 -- 如果需要修改配置，点击 **Previous** 返回并进行相应更改。 +- 若确认所有配置无误，点击 **Create** 继续创建 changefeed。 +- 若需修改配置，点击 **Previous** 返回并进行相应调整。 -sink 很快会启动，你会看到 sink 状态从 **Creating** 变为 **Running**。 +sink 很快会启动，你将看到 sink 状态从 **Creating** 变为 **Running**。 -点击 changefeed 名称可进入详情页面。在该页面，你可以查看更多关于 changefeed 的信息，包括 checkpoint 状态、同步延时及其他相关统计/指标（信息）。 \ No newline at end of file +点击 changefeed 名称可进入详情页面。在该页面，你可以查看更多 changefeed 信息，包括 checkpoint 状态、同步延时及其他相关统计/指标（信息）。 \ No newline at end of file diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 04d1ea267989f..c31885068704f 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -10,9 +10,9 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud Essent ## 限制 - 每个 TiDB Cloud Essential 集群最多可以创建 10 个 changefeed。 -- 目前，TiDB Cloud Essential 不支持上传自签名 TLS 证书以连接到 Kafka broker。 +- 目前，TiDB Cloud Essential 不支持上传自签名 TLS 证书以连接 Kafka broker。 - 由于 TiDB Cloud Essential 使用 TiCDC 建立 changefeed，因此具有与 [TiCDC 相同的限制](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)。 -- 如果需要同步的表没有主键或非 null 唯一索引，在某些重试场景下，由于同步过程中缺少唯一约束，可能会导致下游插入重复数据。 +- 如果待同步的表没有主键或非空唯一索引，在某些重试场景下，由于缺少唯一约束，可能会导致下游插入重复数据。 ## 前提条件 @@ -31,15 +31,16 @@ summary: 本文档介绍如何创建 changefeed，将数据从 TiDB Cloud Essent
-Private Link 连接利用云服务商的 **Private Link** 技术，使你 VPC 中的资源能够通过私有 IP 地址连接到其他 VPC 中的服务，就像这些服务直接托管在你的 VPC 内一样。 +Private link 连接利用云服务商的 **Private Link** 技术，使你 VPC 中的资源能够通过私有 IP 地址连接到其他 VPC 中的服务，就像这些服务直接托管在你的 VPC 内一样。 -TiDB Cloud Essential 目前仅支持自建 Kafka 和 Confluent Cloud Dedicated 集群的 Private Link 连接。不支持与 MSK 或其他 Kafka SaaS 服务的直接集成。 +TiDB Cloud Essential 目前仅支持自建 Kafka、Confluent Cloud Dedicated 集群和 Amazon MSK Provisioned 的 Private Link 连接。不支持与其他 Kafka SaaS 服务的直接集成。 根据你的 Kafka 部署和云服务商，设置 Private Link 连接请参考以下指南： - [通过 Private Link 连接到 AWS 上的 Confluent Cloud](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md) -- [通过 Private Link 连接到 AWS 上的自建 Kafka](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md) +- [通过 Private Link 连接到 AWS 自建 Kafka](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md) - [通过 Private Link 连接到阿里云自建 Kafka](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md) +- [通过 Private Link 连接到 Amazon MSK Provisioned](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)
@@ -54,22 +55,22 @@ TiDB Cloud Essential 目前仅支持自建 Kafka 和 Confluent Cloud Dedicated ### Kafka ACL 授权 -为了让 TiDB Cloud Essential changefeed 能够将数据流式传输到 Apache Kafka 并自动创建 Kafka topic，请确保在 Kafka 中添加了以下权限： +为了允许 TiDB Cloud Essential changefeed 向 Apache Kafka 流式传输数据并自动创建 Kafka topic，请确保在 Kafka 中添加了以下权限： -- 为 Kafka 中的 topic 资源类型添加 `Create` 和 `Write` 权限。 -- 为 Kafka 中的 cluster 资源类型添加 `DescribeConfigs` 权限。 +- 为 Kafka 的 topic 资源类型添加 `Create` 和 `Write` 权限。 +- 为 Kafka 的 cluster 资源类型添加 `DescribeConfigs` 权限。 例如，如果你的 Kafka 集群在 Confluent Cloud，请参考 Confluent 文档中的 [Resources](https://docs.confluent.io/platform/current/kafka/authorization.html#resources) 和 [Adding ACLs](https://docs.confluent.io/platform/current/security/authorization/acls/manage-acls.html#add-acls) 获取更多信息。 -## 第 1 步. 打开 Apache Kafka 的 Changefeed 页面 +## 第 1 步：打开 Apache Kafka 的 Changefeed 页面 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com)。 -2. 进入目标 TiDB Cloud Essential 集群的概览页面，然后点击左侧导航栏的 **Data** > **Changefeed**。 -3. 点击 **Create Changefeed**，然后选择 **Kafka** 作为 **Destination**。 +2. 进入目标 TiDB Cloud Essential 集群的概览页面，然后在左侧导航栏点击 **Data** > **Changefeed**。 +3. 点击 **Create Changefeed**，然后在 **Destination** 选择 **Kafka**。 -## 第 2 步. 配置 changefeed 目标 +## 第 2 步：配置 changefeed 目标 -具体步骤根据你选择的连接方式有所不同。 +根据你选择的连接方式，操作步骤有所不同。
@@ -77,122 +78,122 @@ TiDB Cloud Essential 目前仅支持自建 Kafka 和 Confluent Cloud Dedicated 1. 在 **Connectivity Method** 选择 **Public**，并填写你的 Kafka broker endpoint。多个 endpoint 可用逗号 `,` 分隔。 2. 根据你的 Kafka 认证配置，选择 **Authentication** 选项。 - - 如果你的 Kafka 不需要认证，保持默认选项 **Disable**。 - - 如果你的 Kafka 需要认证，选择相应的认证类型，然后填写 Kafka 账户的 **user name** 和 **password** 进行认证。 + - 如果 Kafka 不需要认证，保持默认选项 **Disable**。 + - 如果 Kafka 需要认证，选择相应的认证类型，并填写 Kafka 账户的 **user name** 和 **password**。 3. 在 **Kafka Version** 选择 **Kafka v2** 或 **Kafka v3**，具体取决于你的 Kafka 版本。 4. 选择本 changefeed 的数据 **Compression** 类型。 -5. 如果你的 Kafka 启用了 TLS 加密，并且你希望为 Kafka 连接使用 TLS 加密，请启用 **TLS Encryption** 选项。 -6. 点击 **Next** 进行网络连接测试。测试通过后会进入下一页面。 +5. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，请启用 **TLS Encryption** 选项。 +6. 点击 **Next** 进行网络测试。如果测试通过，将进入下一页面。
1. 在 **Connectivity Method** 选择 **Private Link**。 2. 在 **Private Link Connection** 选择你在 [网络](#network) 部分创建的 private link 连接。确保 private link 连接的可用区与 Kafka 部署的可用区一致。 -3. 填写你在 [网络](#network) 部分获取的 **Bootstrap Port**。 +3. 填写你在 [网络](#network) 部分获得的 **Bootstrap Port**。如果你使用的是 Amazon MSK Provisioned 的 private link 连接，可以跳过此项。 4. 根据你的 Kafka 认证配置，选择 **Authentication** 选项。 - - 如果你的 Kafka 不需要认证，保持默认选项 **Disable**。 - - 如果你的 Kafka 需要认证，选择相应的认证类型，然后填写 Kafka 账户的 **user name** 和 **password** 进行认证。 + - 如果 Kafka 不需要认证，保持默认选项 **Disable**。 + - 如果 Kafka 需要认证，选择相应的认证类型，并填写 Kafka 账户的 **user name** 和 **password**。 5. 在 **Kafka Version** 选择 **Kafka v2** 或 **Kafka v3**，具体取决于你的 Kafka 版本。 6. 选择本 changefeed 的数据 **Compression** 类型。 -7. 如果你的 Kafka 启用了 TLS 加密，并且你希望为 Kafka 连接使用 TLS 加密，请启用 **TLS Encryption** 选项。 -8. 如果你的 Kafka 需要 TLS SNI 验证，请填写 **TLS Server Name**。例如，`Confluent Cloud Dedicated clusters`。 -9. 点击 **Next** 进行网络连接测试。测试通过后会进入下一页面。 +7. 如果你的 Kafka 启用了 TLS 加密，并希望使用 TLS 加密连接 Kafka，请启用 **TLS Encryption** 选项。 +8. 如果你的 Kafka 需要 TLS SNI 验证，请填写 **TLS Server Name**，例如 `Confluent Cloud Dedicated clusters`。 +9. 点击 **Next** 进行网络测试。如果测试通过，将进入下一页面。
-## 第 3 步. 设置 changefeed +## 第 3 步：设置 changefeed -1. 自定义 **Table Filter**，筛选你希望同步的表。规则语法请参考 [table filter 规则](https://docs.pingcap.com/tidb/stable/table-filter/#syntax)。 +1. 自定义 **Table Filter**，筛选你希望同步的表。规则语法详见 [table filter 规则](https://docs.pingcap.com/tidb/stable/table-filter/#syntax)。 - - **Replication Scope**：你可以选择只同步具有有效键的表，或同步所有选中的表。 - - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。当你添加新规则并点击 **Apply** 后，TiDB Cloud 会查询 TiDB 中的所有表，并在 **Filter results** 下仅显示匹配规则的表。 + - **Replication Scope**：你可以选择仅同步具有有效键的表，或同步所有选中的表。 + - **Filter Rules**：你可以在此列设置过滤规则。默认有一条规则 `*.*`，表示同步所有表。添加新规则并点击 **Apply** 后，TiDB Cloud 会查询 TiDB 中所有表，并仅显示符合规则的表在 **Filter results** 下。 - **Case Sensitive**：你可以设置过滤规则中数据库和表名的匹配是否大小写敏感。默认情况下，匹配不区分大小写。 - **Filter results with valid keys**：此列显示具有有效键（包括主键或唯一索引）的表。 - **Filter results without valid keys**：此列显示缺少主键或唯一键的表。这些表在同步时存在挑战，因为缺少唯一标识符可能导致下游处理重复事件时数据不一致。为保证数据一致性，建议在同步前为这些表添加唯一键或主键，或者通过添加过滤规则排除这些表。例如，可以通过规则 `"!test.tbl1"` 排除表 `test.tbl1`。 2. 自定义 **Event Filter**，筛选你希望同步的事件。 - - **Tables matching**：你可以在此列设置事件过滤器应用到哪些表。规则语法与前述 **Table Filter** 区域相同。 - - **Event Filter**：你可以选择需要忽略的事件。 + - **Tables matching**：你可以设置事件过滤器应用于哪些表。规则语法与前述 **Table Filter** 区域相同。 + - **Event Filter**：你可以选择要忽略的事件。 -3. 自定义 **Column Selector**，从事件中选择列，仅将这些列相关的数据变更发送到下游。 +3. 自定义 **Column Selector**，选择事件中的列，仅将这些列的数据变更发送到下游。 - - **Tables matching**：指定 column selector 应用到哪些表。未匹配任何规则的表将发送所有列。 - - **Column Selector**：指定匹配表中哪些列会被发送到下游。 + - **Tables matching**：指定 column selector 应用于哪些表。未匹配任何规则的表将发送所有列。 + - **Column Selector**：指定匹配表中要发送到下游的列。 更多匹配规则说明，参见 [Column selectors](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-kafka/#column-selectors)。 4. 在 **Data Format** 区域，选择你期望的 Kafka 消息格式。 - - Avro 是一种紧凑、高效、二进制的数据格式，拥有丰富的数据结构，被广泛应用于各种流式系统。更多信息参见 [Avro data format](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)。 - - Canal-JSON 是一种纯 JSON 文本格式，易于解析。更多信息参见 [Canal-JSON data format](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)。 - - Open Protocol 是一种行级数据变更通知协议，为监控、缓存、全文索引、分析引擎以及不同数据库间主从复制等场景提供数据源。更多信息参见 [Open Protocol data format](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)。 - - Debezium 是一个捕获数据库变更的工具。它将每个捕获到的数据库变更转换为一个称为“事件”的消息，并将这些事件发送到 Kafka。更多信息参见 [Debezium data format](https://docs.pingcap.com/tidb/stable/ticdc-debezium)。 + - Avro 是一种紧凑、高效的二进制数据格式，支持丰富的数据结构，广泛应用于各种流式系统。详见 [Avro data format](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)。 + - Canal-JSON 是一种纯 JSON 文本格式，易于解析。详见 [Canal-JSON data format](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)。 + - Open Protocol 是一种行级数据变更通知协议，可为监控、缓存、全文索引、分析引擎以及不同数据库间主从复制等场景提供数据源。详见 [Open Protocol data format](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)。 + - Debezium 是一个捕获数据库变更的工具。它将每个捕获到的数据库变更转换为一个称为“事件”的消息，并将这些事件发送到 Kafka。详见 [Debezium data format](https://docs.pingcap.com/tidb/stable/ticdc-debezium)。 -5. 如果你希望在 Kafka 消息体中添加 TiDB 扩展字段，请启用 **TiDB Extension** 选项。 +5. 如果你希望在 Kafka 消息体中添加 TiDB-extension 字段，请启用 **TiDB Extension** 选项。 - 有关 TiDB 扩展字段的更多信息，参见 [Avro 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields) 和 [Canal-JSON 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。 + 有关 TiDB-extension 字段的更多信息，参见 [Avro 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields) 和 [Canal-JSON 数据格式中的 TiDB 扩展字段](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)。 6. 如果你选择 **Avro** 作为数据格式，页面会显示一些 Avro 专属配置。你可以按如下方式填写： - 在 **Decimal** 和 **Unsigned BigInt** 配置项中，指定 TiDB Cloud 如何在 Kafka 消息中处理 decimal 和 unsigned bigint 数据类型。 - 在 **Schema Registry** 区域，填写你的 schema registry endpoint。如果启用 **HTTP Authentication**，请输入用户名和密码。 -7. 在 **Topic Distribution** 区域，选择一种分发模式，并根据所选模式填写 topic 名称配置。 +7. 在 **Topic Distribution** 区域，选择分发模式，并根据所选模式填写 topic 名称配置。 如果你选择 **Avro** 作为数据格式，则只能在 **Distribution Mode** 下拉列表中选择 **Distribute changelogs by table to Kafka Topics** 模式。 - 分发模式控制 changefeed 如何创建 Kafka topic：按表、按数据库，或为所有 changelog 创建一个 topic。 + 分发模式控制 changefeed 如何创建 Kafka topic：按表、按数据库，或所有变更日志共用一个 topic。 - **Distribute changelogs by table to Kafka Topics** - 如果你希望 changefeed 为每个表创建一个专用的 Kafka topic，请选择此模式。这样，某个表的所有 Kafka 消息都会发送到专用的 Kafka topic。你可以通过设置 topic 前缀、数据库名与表名之间的分隔符以及后缀自定义表的 topic 名称。例如，如果分隔符设置为 `_`，则 topic 名称格式为 `_`。 + 如果你希望 changefeed 为每个表创建一个专用 Kafka topic，请选择此模式。这样，某个表的所有 Kafka 消息都会发送到专用的 Kafka topic。你可以通过设置 topic 前缀、数据库名与表名之间的分隔符以及后缀自定义 topic 名称。例如，分隔符设置为 `_` 时，topic 名称格式为 `_`。 - 对于非行事件（如 Create Schema Event）的 changelog，你可以在 **Default Topic Name** 字段中指定 topic 名称。changefeed 会相应创建 topic 来收集这些 changelog。 + 对于非行事件（如 Create Schema Event）的变更日志，可以在 **Default Topic Name** 字段指定 topic 名称。changefeed 会相应创建 topic 收集此类变更日志。 - **Distribute changelogs by database to Kafka Topics** - 如果你希望 changefeed 为每个数据库创建一个专用的 Kafka topic，请选择此模式。这样，某个数据库的所有 Kafka 消息都会发送到专用的 Kafka topic。你可以通过设置 topic 前缀和后缀自定义数据库的 topic 名称。 + 如果你希望 changefeed 为每个数据库创建一个专用 Kafka topic，请选择此模式。这样，某个数据库的所有 Kafka 消息都会发送到专用的 Kafka topic。你可以通过设置 topic 前缀和后缀自定义数据库的 topic 名称。 - 对于非行事件（如 Resolved Ts Event）的 changelog，你可以在 **Default Topic Name** 字段中指定 topic 名称。changefeed 会相应创建 topic 来收集这些 changelog。 + 对于非行事件（如 Resolved Ts Event）的变更日志，可以在 **Default Topic Name** 字段指定 topic 名称。changefeed 会相应创建 topic 收集此类变更日志。 - **Send all changelogs to one specified Kafka Topic** - 如果你希望 changefeed 为所有 changelog 创建一个 Kafka topic，请选择此模式。这样，changefeed 中的所有 Kafka 消息都会发送到同一个 Kafka topic。你可以在 **Topic Name** 字段中定义 topic 名称。 + 如果你希望 changefeed 为所有变更日志创建一个 Kafka topic，请选择此模式。这样，changefeed 中的所有 Kafka 消息都会发送到同一个 Kafka topic。你可以在 **Topic Name** 字段定义 topic 名称。 8. 在 **Partition Distribution** 区域，你可以决定 Kafka 消息将被发送到哪个分区。你可以为所有表定义 **单一分区分发器**，也可以为不同表定义 **不同的分区分发器**。TiDB Cloud 提供四种分发器类型： - **Distribute changelogs by primary key or index value to Kafka partition** - 如果你希望 changefeed 将某个表的 Kafka 消息发送到不同分区，请选择此分发方式。行级 changelog 的主键或索引值将决定该 changelog 被发送到哪个分区。如果你希望使用主键，请保持 **Index Name** 字段为空。此分发方式能更好地实现分区均衡，并保证行级有序性。 + 如果你希望 changefeed 将某个表的 Kafka 消息发送到不同分区，请选择此分发方式。行变更日志的主键或索引值将决定其被发送到哪个分区。若希望使用主键，可将 **Index Name** 字段留空。此分发方式可获得更好的分区均衡，并保证行级有序。 - **Distribute changelogs by table to Kafka partition** - 如果你希望 changefeed 将某个表的 Kafka 消息发送到同一个 Kafka 分区，请选择此分发方式。行级 changelog 的表名将决定该 changelog 被发送到哪个分区。此分发方式保证表级有序性，但可能导致分区不均衡。 + 如果你希望 changefeed 将某个表的 Kafka 消息发送到同一个 Kafka 分区，请选择此分发方式。行变更日志的表名将决定其被发送到哪个分区。此分发方式保证表级有序，但可能导致分区不均衡。 - **Distribute changelogs by timestamp to Kafka partition** - 如果你希望 changefeed 随机将 Kafka 消息发送到不同的 Kafka 分区，请选择此分发方式。行级 changelog 的 commitTs 将决定该 changelog 被发送到哪个分区。此分发方式能更好地实现分区均衡，并保证每个分区内的有序性。但同一数据项的多次变更可能会被发送到不同分区，不同消费者的消费进度也可能不同，可能导致数据不一致。因此，消费者需要在消费前根据 commitTs 对来自多个分区的数据进行排序。 + 如果你希望 changefeed 随机将 Kafka 消息发送到不同分区，请选择此分发方式。行变更日志的 commitTs 将决定其被发送到哪个分区。此分发方式可获得更好的分区均衡，并保证每个分区内有序。但同一数据项的多次变更可能被发送到不同分区，不同消费者的消费进度可能不同，可能导致数据不一致。因此，消费者需要在消费前按 commitTs 对多个分区的数据进行排序。 - **Distribute changelogs by column value to Kafka partition** - 如果你希望 changefeed 将某个表的 Kafka 消息发送到不同分区，请选择此分发方式。行级 changelog 的指定列值将决定该 changelog 被发送到哪个分区。此分发方式保证每个分区内的有序性，并确保具有相同列值的 changelog 被发送到同一个分区。 + 如果你希望 changefeed 将某个表的 Kafka 消息发送到不同分区，请选择此分发方式。行变更日志中指定列的值将决定其被发送到哪个分区。此分发方式保证每个分区内有序，并确保具有相同列值的变更日志被发送到同一分区。 9. 在 **Topic Configuration** 区域，配置以下数值。changefeed 会根据这些数值自动创建 Kafka topic。 - **Replication Factor**：控制每条 Kafka 消息会被复制到多少台 Kafka 服务器。有效取值范围为 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas) 到 Kafka broker 数量。 - **Partition Number**：控制一个 topic 下有多少分区。有效取值范围为 `[1, 10 * Kafka broker 数量]`。 -10. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件拆分为单独的 `DELETE` 和 `INSERT` 事件，或保持为原始 `UPDATE` 事件。更多信息参见 [为非 MySQL sink 拆分主键或唯一键 UPDATE 事件](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 +10. 在 **Split Event** 区域，选择是否将 `UPDATE` 事件切分为独立的 `DELETE` 和 `INSERT` 事件，或保持为原始 `UPDATE` 事件。详见 [为非 MySQL sink 切分主键或唯一键 UPDATE 事件](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)。 11. 点击 **Next**。 -## 第 4 步. 审核并创建 changefeed +## 第 4 步：审核并创建 changefeed 1. 在 **Changefeed Name** 区域，为 changefeed 指定一个名称。 2. 审核你设置的所有 changefeed 配置。如需修改，点击 **Previous** 返回修改。 diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index 5d721f906ec1f..8d989402e52e9 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -7,47 +7,47 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 本文档介绍如何将 CSV 文件从 Amazon Simple Storage Service（Amazon S3）、Google Cloud Storage（GCS）、Azure Blob Storage 或阿里云对象存储服务（OSS）导入到 TiDB Cloud Starter 或 TiDB Cloud Essential。 -> **Note:** +> **注意：** > -> 关于 TiDB Cloud Dedicated，请参见 [从云存储导入 CSV 文件到 TiDB Cloud Dedicated](/tidb-cloud/import-csv-files.md)。 +> 如果你使用的是 TiDB Cloud Dedicated，请参阅 [从云存储导入 CSV 文件到 TiDB Cloud Dedicated](/tidb-cloud/import-csv-files.md)。 ## 限制 -- 为保证数据一致性，TiDB Cloud 仅允许将 CSV 文件导入到空表中。若需将数据导入到已存在且包含数据的表中，你可以按照本文档的方式先将数据导入到一个临时空表，然后使用 `INSERT SELECT` 语句将数据复制到目标表。 +- 为确保数据一致性，TiDB Cloud 仅允许将 CSV 文件导入到空表中。如果你需要将数据导入到已存在且包含数据的表中，可以按照本文档的方式，先将数据导入到一个临时空表，然后使用 `INSERT SELECT` 语句将数据复制到目标已存在的表中。 ## 第 1 步：准备 CSV 文件 -1. 如果单个 CSV 文件大于 256 MiB，建议将其拆分为多个小文件，每个文件大小约为 256 MiB。 +1. 如果单个 CSV 文件大于 256 MiB，建议将其切分为多个小文件，每个文件大小约为 256 MiB。 - TiDB Cloud 支持导入非常大的 CSV 文件，但在多个约 256 MiB 的输入文件时性能最佳。这是因为 TiDB Cloud 可以并行处理多个文件，从而大幅提升导入速度。 + TiDB Cloud 支持导入非常大的 CSV 文件，但当输入文件为多个且每个约 256 MiB 时，性能最佳。这是因为 TiDB Cloud 可以并行处理多个文件，从而大幅提升导入速度。 2. 按如下方式命名 CSV 文件： - - 如果一个 CSV 文件包含了整个表的所有数据，文件名应采用 `${db_name}.${table_name}.csv` 格式，导入时会映射到 `${db_name}.${table_name}` 表。 - - 如果一个表的数据被拆分为多个 CSV 文件，应在这些文件名后添加数字后缀。例如，`${db_name}.${table_name}.000001.csv` 和 `${db_name}.${table_name}.000002.csv`。数字后缀可以不连续，但必须递增，并且需要在数字前补零以保证所有后缀长度一致。 - - TiDB Cloud 支持导入以下格式的压缩文件：`.gzip`、`.gz`、`.zstd`、`.zst` 和 `.snappy`。如果你需要导入压缩的 CSV 文件，文件名应采用 `${db_name}.${table_name}.${suffix}.csv.${compress}` 格式，其中 `${suffix}` 可选，可以是任意整数如 '000001'。例如，如果你想将 `trips.000001.csv.gz` 文件导入到 `bikeshare.trips` 表，需要将文件重命名为 `bikeshare.trips.000001.csv.gz`。 + - 如果一个 CSV 文件包含整个表的所有数据，文件名应采用 `${db_name}.${table_name}.csv` 格式，导入时会映射到 `${db_name}.${table_name}` 表。 + - 如果一个表的数据被拆分为多个 CSV 文件，应在这些 CSV 文件名后添加数字后缀。例如，`${db_name}.${table_name}.000001.csv` 和 `${db_name}.${table_name}.000002.csv`。数字后缀可以不连续，但必须为正序。你还需要在数字前补零，确保所有后缀长度一致。 + - TiDB Cloud 支持导入以下格式的压缩文件：`.gzip`、`.gz`、`.zstd`、`.zst` 和 `.snappy`。如果你需要导入压缩的 CSV 文件，文件名应采用 `${db_name}.${table_name}.${suffix}.csv.${compress}` 格式，其中 `${suffix}` 可选，可以是任意整数，如 '000001'。例如，如果你要将 `trips.000001.csv.gz` 文件导入到 `bikeshare.trips` 表，需要将文件重命名为 `bikeshare.trips.000001.csv.gz`。 - > **Note:** + > **注意：** > > - 为获得更好的性能，建议每个压缩文件大小不超过 100 MiB。 - > - Snappy 压缩文件必须为 [官方 Snappy 格式](https://github.com/google/snappy)。不支持其他 Snappy 压缩变体。 - > - 对于未压缩的文件，如果你在某些情况下无法按照上述规则修改 CSV 文件名（例如这些 CSV 文件链接也被其他程序使用），可以保持文件名不变，并在 [第 4 步](#step-4-import-csv-files) 的 **Mapping Settings** 中将源数据导入到单一目标表。 + > - Snappy 压缩文件必须为 [官方 Snappy 格式](https://github.com/google/snappy)。不支持其他变体的 Snappy 压缩格式。 + > - 对于未压缩的文件，如果你在某些情况下无法按照上述规则修改 CSV 文件名（例如，CSV 文件链接也被你的其他程序使用），可以保持文件名不变，并在 [第 4 步](#step-4-import-csv-files) 的 **Mapping Settings** 中，将源数据导入到单一目标表。 ## 第 2 步：创建目标表结构 -由于 CSV 文件不包含表结构信息，在将 CSV 文件数据导入 TiDB Cloud 之前，你需要通过以下任一方式创建表结构： +由于 CSV 文件不包含表结构信息，在将 CSV 文件中的数据导入 TiDB Cloud 之前，你需要通过以下任一方法创建表结构： -- 方法一：在 TiDB Cloud 中为你的源数据创建目标数据库和数据表。 +- 方法 1：在 TiDB Cloud 中，为你的源数据创建目标数据库和表。 -- 方法二：在存放 CSV 文件的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下，为你的源数据创建目标表结构文件： +- 方法 2：在存放 CSV 文件的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下，为你的源数据创建目标表结构文件： 1. 为你的源数据创建数据库结构文件。 - 如果你的 CSV 文件遵循 [第 1 步](#step-1-prepare-the-csv-files) 的命名规则，则导入数据时数据库结构文件为可选项。否则，数据库结构文件为必需项。 + 如果你的 CSV 文件遵循 [第 1 步](#step-1-prepare-the-csv-files) 的命名规则，则数据库结构文件在数据导入时为可选项。否则，数据库结构文件为必需项。 每个数据库结构文件必须采用 `${db_name}-schema-create.sql` 格式，并包含一个 `CREATE DATABASE` DDL 语句。通过该文件，TiDB Cloud 会在导入数据时创建 `${db_name}` 数据库以存储你的数据。 - 例如，如果你创建了一个包含如下语句的 `mydb-scehma-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 + 例如，如果你创建了一个包含如下语句的 `mydb-schema-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 ```sql CREATE DATABASE mydb; @@ -55,11 +55,11 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 2. 为你的源数据创建表结构文件。 - 如果你没有在存放 CSV 文件的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建相应的数据表。 + 如果你没有在存放 CSV 文件的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建相应的表。 - 每个表结构文件必须采用 `${db_name}.${table_name}-schema.sql` 格式，并包含一个 `CREATE TABLE` DDL 语句。通过该文件，TiDB Cloud 会在 `${db_name}` 数据库中创建 `${db_table}` 表以存储你的数据。 + 每个表结构文件必须采用 `${db_name}.${table_name}-schema.sql` 格式，并包含一个 `CREATE TABLE` DDL 语句。通过该文件，TiDB Cloud 会在导入数据时，在 `${db_name}` 数据库中创建 `${db_table}` 表。 - 例如，如果你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在 `mydb` 数据库中创建 `mytable` 表。 + 例如，如果你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在导入数据时，在 `mydb` 数据库中创建 `mytable` 表。 ```sql CREATE TABLE mytable ( @@ -68,23 +68,23 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 COUNT INT ); ``` - > **Note:** + > **注意：** > > 每个 `${db_name}.${table_name}-schema.sql` 文件只能包含一个 DDL 语句。如果文件中包含多个 DDL 语句，只有第一个会生效。 -## 第 3 步：配置跨账号访问 +## 第 3 步：配置跨账户访问 -为了让 TiDB Cloud 能访问 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务桶中的 CSV 文件，请按以下方式操作： +为了让 TiDB Cloud 能够访问 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务 bucket 中的 CSV 文件，请执行以下操作之一： -- 如果你的 CSV 文件位于 Amazon S3，请为集群 [配置 Amazon S3 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- 如果你的 CSV 文件位于 Amazon S3，请为你的集群 [配置 Amazon S3 访问](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 - 你可以使用 AWS 访问密钥或 Role ARN 访问你的桶。配置完成后，请记录访问密钥（包括访问密钥 ID 和密钥）或 Role ARN 值，后续在 [第 4 步](#step-4-import-csv-files) 中会用到。 + 你可以使用 AWS 访问密钥或 Role ARN 访问你的 bucket。完成后，请记录访问密钥（包括访问密钥 ID 和密钥）或 Role ARN 值，在 [第 4 步](#step-4-import-csv-files) 中会用到。 -- 如果你的 CSV 文件位于 GCS，请为集群 [配置 GCS 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 +- 如果你的 CSV 文件位于 GCS，请为你的集群 [配置 GCS 访问](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 -- 如果你的 CSV 文件位于 Azure Blob Storage，请为集群 [配置 Azure Blob Storage 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 +- 如果你的 CSV 文件位于 Azure Blob Storage，请为你的集群 [配置 Azure Blob Storage 访问](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 -- 如果你的 CSV 文件位于阿里云对象存储服务（OSS），请为集群 [配置阿里云对象存储服务（OSS）访问权限](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- 如果你的 CSV 文件位于阿里云对象存储服务（OSS），请为你的集群 [配置阿里云对象存储服务（OSS）访问](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 ## 第 4 步：导入 CSV 文件 @@ -95,13 +95,13 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > - > 你可以使用左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -109,9 +109,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 - **Storage Provider**：选择 **Amazon S3**。 - **Source Files URI**： - - 导入单个文件时，输入源文件 URI，格式为 `s3://[bucket_name]/[data_source_folder]/[file_name].csv`。例如：`s3://sampledata/ingest/TableName.01.csv`。 - - 导入多个文件时，输入源文件夹 URI，格式为 `s3://[bucket_name]/[data_source_folder]/`。例如：`s3://sampledata/ingest/`。 - - **Credential**：你可以使用 AWS Role ARN 或 AWS 访问密钥访问你的桶。详情请参见 [配置 Amazon S3 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 + - 导入单个文件时，输入源文件 URI，格式为 `s3://[bucket_name]/[data_source_folder]/[file_name].csv`。例如，`s3://sampledata/ingest/TableName.01.csv`。 + - 导入多个文件时，输入源文件夹 URI，格式为 `s3://[bucket_name]/[data_source_folder]/`。例如，`s3://sampledata/ingest/`。 + - **Credential**：你可以使用 AWS Role ARN 或 AWS 访问密钥访问你的 bucket。详情参见 [配置 Amazon S3 访问](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 - **AWS Role ARN**：输入 AWS Role ARN 值。 - **AWS Access Key**：输入 AWS 访问密钥 ID 和 AWS 密钥。 @@ -121,9 +121,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > - > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表即可。 + > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。在这种情况下，你只需选择目标数据库和表进行数据导入。 - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **CSV** 作为数据格式。 @@ -138,9 +138,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 查看扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 -8. 当导入进度显示 **Completed** 时，检查已导入的数据表。 +8. 当导入进度显示 **Completed** 时，检查已导入的表。
@@ -148,13 +148,13 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > - > 你可以使用左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -162,9 +162,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 - **Storage Provider**：选择 **Google Cloud Storage**。 - **Source Files URI**： - - 导入单个文件时，输入源文件 URI，格式为 `[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].csv`。例如：`[gcs|gs]://sampledata/ingest/TableName.01.csv`。 - - 导入多个文件时，输入源文件夹 URI，格式为 `[gcs|gs]://[bucket_name]/[data_source_folder]/`。例如：`[gcs|gs]://sampledata/ingest/`。 - - **Credential**：你可以使用 GCS IAM Role Service Account key 访问你的桶。详情请参见 [配置 GCS 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 + - 导入单个文件时，输入源文件 URI，格式为 `[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].csv`。例如，`[gcs|gs]://sampledata/ingest/TableName.01.csv`。 + - 导入多个文件时，输入源文件夹 URI，格式为 `[gcs|gs]://[bucket_name]/[data_source_folder]/`。例如，`[gcs|gs]://sampledata/ingest/`。 + - **Credential**：你可以使用 GCS IAM Role Service Account 密钥访问你的 bucket。详情参见 [配置 GCS 访问](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 4. 点击 **Next**。 @@ -172,9 +172,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > - > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表即可。 + > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。在这种情况下，你只需选择目标数据库和表进行数据导入。 - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **CSV** 作为数据格式。 @@ -189,9 +189,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 查看扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 -8. 当导入进度显示 **Completed** 时，检查已导入的数据表。 +8. 当导入进度显示 **Completed** 时，检查已导入的表。
@@ -199,13 +199,13 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > - > 你可以使用左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -213,9 +213,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 - **Storage Provider**：选择 **Azure Blob Storage**。 - **Source Files URI**： - - 导入单个文件时，输入源文件 URI，格式为 `[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`。例如：`[azure|https]://sampledata/ingest/TableName.01.csv`。 - - 导入多个文件时，输入源文件夹 URI，格式为 `[azure|https]://[bucket_name]/[data_source_folder]/`。例如：`[azure|https]://sampledata/ingest/`。 - - **Credential**：你可以使用共享访问签名（SAS）令牌访问你的桶。详情请参见 [配置 Azure Blob Storage 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 + - 导入单个文件时，输入源文件 URI，格式为 `[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`。例如，`[azure|https]://sampledata/ingest/TableName.01.csv`。 + - 导入多个文件时，输入源文件夹 URI，格式为 `[azure|https]://[bucket_name]/[data_source_folder]/`。例如，`[azure|https]://sampledata/ingest/`。 + - **Credential**：你可以使用共享访问签名（SAS）令牌访问你的 bucket。详情参见 [配置 Azure Blob Storage 访问](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 4. 点击 **Next**。 @@ -223,9 +223,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > - > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表即可。 + > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。在这种情况下，你只需选择目标数据库和表进行数据导入。 - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **CSV** 作为数据格式。 @@ -240,9 +240,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 查看扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 -8. 当导入进度显示 **Completed** 时，检查已导入的数据表。 +8. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -250,13 +250,13 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > - > 你可以使用左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -264,9 +264,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 - **Storage Provider**：选择 **Alibaba Cloud OSS**。 - **Source Files URI**： - - 导入单个文件时，输入源文件 URI，格式为 `oss://[bucket_name]/[data_source_folder]/[file_name].csv`。例如：`oss://sampledata/ingest/TableName.01.csv`。 - - 导入多个文件时，输入源文件夹 URI，格式为 `oss://[bucket_name]/[data_source_folder]/`。例如：`oss://sampledata/ingest/`。 - - **Credential**：你可以使用 AccessKey 对访问你的桶。详情请参见 [配置阿里云对象存储服务（OSS）访问权限](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 + - 导入单个文件时，输入源文件 URI，格式为 `oss://[bucket_name]/[data_source_folder]/[file_name].csv`。例如，`oss://sampledata/ingest/TableName.01.csv`。 + - 导入多个文件时，输入源文件夹 URI，格式为 `oss://[bucket_name]/[data_source_folder]/`。例如，`oss://sampledata/ingest/`。 + - **Credential**：你可以使用 AccessKey 对访问你的 bucket。详情参见 [配置阿里云对象存储服务（OSS）访问](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 4. 点击 **Next**。 @@ -274,9 +274,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > - > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表即可。 + > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。在这种情况下，你只需选择目标数据库和表进行数据导入。 - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **CSV** 作为数据格式。 @@ -291,9 +291,9 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 查看扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 -8. 当导入进度显示 **Completed** 时，检查已导入的数据表。 +8. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -303,7 +303,7 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 如果你遇到导入错误，请按以下步骤操作： -1. 删除部分导入的表。 +1. 删除部分已导入的表。 2. 检查表结构文件，如有错误请修正。 3. 检查 CSV 文件中的数据类型。 4. 重新尝试导入任务。 @@ -312,10 +312,10 @@ summary: 了解如何将 CSV 文件从 Amazon S3、GCS、Azure Blob Storage 或 ### 解决数据导入过程中的警告 -点击 **Start Import** 后，如果你看到类似 `can't find the corresponding source files` 的警告信息，请通过提供正确的源文件、根据 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。 +点击 **Start Import** 后，如果你看到类似 `can't find the corresponding source files` 的警告信息，请通过提供正确的源文件、根据 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md)重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。 解决这些问题后，你需要重新导入数据。 ### 导入表中行数为零 -当导入进度显示 **Completed** 后，检查已导入的数据表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，请通过提供正确的源文件、根据 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后，重新导入这些表。 \ No newline at end of file +当导入进度显示 **Completed** 后，检查已导入的表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，请通过提供正确的源文件、根据 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md)重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后，重新导入这些表。 \ No newline at end of file diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index 73b0ed951fcf8..5539edd27512b 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -1,45 +1,45 @@ --- -title: 从云存储导入 CSV 文件到 TiDB Cloud 专属集群 -summary: 了解如何将 CSV 文件从 Amazon S3、GCS 或 Azure Blob Storage 导入到 TiDB Cloud 专属集群。 -aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-aurora-bulk-import'] +title: 从云存储导入 CSV 文件到 TiDB Cloud Dedicated +summary: 了解如何将 CSV 文件从 Amazon S3、GCS 或 Azure Blob Storage 导入到 TiDB Cloud Dedicated。 +aliases: ['/zh/tidbcloud/migrate-from-amazon-s3-or-gcs','/zh/tidbcloud/migrate-from-aurora-bulk-import'] --- -# 从云存储导入 CSV 文件到 TiDB Cloud 专属集群 +# 从云存储导入 CSV 文件到 TiDB Cloud Dedicated -本文档介绍如何将 CSV 文件从 Amazon Simple Storage Service（Amazon S3）、Google Cloud Storage（GCS）或 Azure Blob Storage 导入到 TiDB Cloud 专属集群。 +本文档介绍如何将 CSV 文件从 Amazon Simple Storage Service（Amazon S3）、Google Cloud Storage（GCS）或 Azure Blob Storage 导入到 TiDB Cloud Dedicated。 ## 限制 -- 为确保数据一致性，TiDB Cloud 仅允许将 CSV 文件导入到空表中。若需将数据导入到已存在数据的表中，你可以按照本文档的步骤，先将数据导入到一个临时空表中，然后使用 `INSERT SELECT` 语句将数据复制到目标表。 +- 为保证数据一致性，TiDB Cloud 仅允许将 CSV 文件导入到空表中。若需将数据导入已存在且包含数据的表，可以按照本文档的步骤，先将数据导入到一个临时空表，再通过 `INSERT SELECT` 语句将数据复制到目标已存在的表中。 -- 如果 TiDB Cloud 专属集群已开启 [changefeed](/tidb-cloud/changefeed-overview.md) 或 [时间点恢复（Point-in-time Restore）](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)，则无法向该集群导入数据（**Import Data** 按钮会被禁用），因为当前数据导入功能使用的是 [物理导入模式](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)。在该模式下，导入的数据不会生成变更日志，因此 changefeed 和时间点恢复无法检测到导入的数据。 +- 如果 TiDB Cloud Dedicated 集群已开启 [changefeed](/tidb-cloud/changefeed-overview.md) 或已启用 [Point-in-time Restore](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)，则无法向该集群导入数据（**Import Data** 按钮会被禁用），因为当前数据导入功能使用的是 [physical import mode](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)。在该模式下，导入的数据不会生成变更日志，因此 changefeed 和 Point-in-time Restore 无法检测到导入的数据。 ## 第 1 步：准备 CSV 文件 -1. 如果单个 CSV 文件大于 256 MiB，建议将其拆分为多个小文件，每个文件大小约为 256 MiB。 +1. 如果单个 CSV 文件大于 256 MiB，建议将其切分为更小的文件，每个文件大小约为 256 MiB。 TiDB Cloud 支持导入非常大的 CSV 文件，但在多个约 256 MiB 的输入文件时性能最佳。这是因为 TiDB Cloud 可以并行处理多个文件，从而大幅提升导入速度。 2. 按如下方式命名 CSV 文件： - 如果一个 CSV 文件包含整个表的所有数据，文件名应采用 `${db_name}.${table_name}.csv` 格式，导入时会映射到 `${db_name}.${table_name}` 表。 - - 如果一个表的数据被拆分为多个 CSV 文件，应在这些文件名后添加数字后缀。例如，`${db_name}.${table_name}.000001.csv` 和 `${db_name}.${table_name}.000002.csv`。数字后缀可以不连续，但必须递增，并且需要在数字前补零以保证所有后缀长度一致。 - - TiDB Cloud 支持导入以下格式的压缩文件：`.gzip`、`.gz`、`.zstd`、`.zst` 和 `.snappy`。如果你需要导入压缩的 CSV 文件，文件名应采用 `${db_name}.${table_name}.${suffix}.csv.${compress}` 格式，其中 `${suffix}` 可选，可以是任意整数（如 '000001'）。例如，若要将 `trips.000001.csv.gz` 文件导入到 `bikeshare.trips` 表，需要将文件重命名为 `bikeshare.trips.000001.csv.gz`。 + - 如果一个表的数据被拆分为多个 CSV 文件，应在这些 CSV 文件名后添加数字后缀。例如，`${db_name}.${table_name}.000001.csv` 和 `${db_name}.${table_name}.000002.csv`。数字后缀可以不连续，但必须为正序，并且需要在数字前补零以保证所有后缀长度一致。 + - TiDB Cloud 支持导入以下格式的压缩文件：`.gzip`、`.gz`、`.zstd`、`.zst` 和 `.snappy`。如需导入压缩的 CSV 文件，文件名应采用 `${db_name}.${table_name}.${suffix}.csv.${compress}` 格式，其中 `${suffix}` 可选，可以是任意整数（如 '000001'）。例如，若需将 `trips.000001.csv.gz` 文件导入到 `bikeshare.trips` 表，需要将文件重命名为 `bikeshare.trips.000001.csv.gz`。 > **注意：** > - > - 你只需压缩数据文件，无需压缩数据库或表结构文件。 + > - 只需压缩数据文件，无需压缩数据库或表结构文件。 > - 为获得更好的性能，建议每个压缩文件大小不超过 100 MiB。 - > - Snappy 压缩文件必须采用 [官方 Snappy 格式](https://github.com/google/snappy)，不支持其他变体。 - > - 对于未压缩的文件，如果你无法按上述规则修改 CSV 文件名（例如，CSV 文件链接也被其他程序使用），可以保持文件名不变，并在 [第 4 步](#step-4-import-csv-files-to-tidb-cloud) 的 **Mapping Settings** 中将源数据导入到单个目标表。 + > - Snappy 压缩文件必须为 [官方 Snappy 格式](https://github.com/google/snappy)，不支持其他变体的 Snappy 压缩格式。 + > - 对于未压缩的文件，如果在某些场景下无法按照上述规则修改 CSV 文件名（例如，CSV 文件链接也被其他程序使用），可以保持文件名不变，并在 [第 4 步](#step-4-import-csv-files-to-tidb-cloud) 的 **Mapping Settings** 中将源数据导入到单个目标表。 ## 第 2 步：创建目标表结构 -由于 CSV 文件不包含表结构信息，在将 CSV 文件数据导入 TiDB Cloud 之前，你需要通过以下任一方式创建表结构： +由于 CSV 文件不包含表结构信息，在将 CSV 文件中的数据导入 TiDB Cloud 之前，需要通过以下任一方法创建表结构： -- 方式一：在 TiDB Cloud 中为你的源数据创建目标数据库和数据表。 +- 方法 1：在 TiDB Cloud 中，为你的源数据创建目标数据库和表。 -- 方式二：在存放 CSV 文件的 Amazon S3、GCS 或 Azure Blob Storage 目录下，为你的源数据创建目标表结构文件，具体如下： +- 方法 2：在存放 CSV 文件的 Amazon S3、GCS 或 Azure Blob Storage 目录下，为你的源数据创建目标表结构文件，具体如下： 1. 为你的源数据创建数据库结构文件。 @@ -47,7 +47,7 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au 每个数据库结构文件必须采用 `${db_name}-schema-create.sql` 格式，并包含一个 `CREATE DATABASE` DDL 语句。通过该文件，TiDB Cloud 会在导入数据时创建 `${db_name}` 数据库以存储你的数据。 - 例如，如果你创建了一个包含如下语句的 `mydb-scehma-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 + 例如，若你创建了一个包含如下语句的 `mydb-schema-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 ```sql @@ -56,11 +56,11 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au 2. 为你的源数据创建表结构文件。 - 如果你没有在存放 CSV 文件的 Amazon S3、GCS 或 Azure Blob Storage 目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建相应的数据表。 + 如果你未在存放 CSV 文件的 Amazon S3、GCS 或 Azure Blob Storage 目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建相应的表。 每个表结构文件必须采用 `${db_name}.${table_name}-schema.sql` 格式，并包含一个 `CREATE TABLE` DDL 语句。通过该文件，TiDB Cloud 会在 `${db_name}` 数据库中创建 `${db_table}` 表以存储你的数据。 - 例如，如果你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在导入数据时在 `mydb` 数据库中创建 `mytable` 表。 + 例如，若你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在导入数据时在 `mydb` 数据库中创建 `mytable` 表。 ```sql @@ -72,36 +72,36 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au > **注意：** > - > 每个 `${db_name}.${table_name}-schema.sql` 文件只能包含一个 DDL 语句。如果文件中包含多个 DDL 语句，只有第一个会生效。 + > 每个 `${db_name}.${table_name}-schema.sql` 文件只能包含一个 DDL 语句。如果文件中包含多个 DDL 语句，仅第一个生效。 -## 第 3 步：配置跨账号访问 +## 第 3 步：配置跨账户访问 -为了让 TiDB Cloud 能够访问 Amazon S3、GCS 或 Azure Blob Storage 中的 CSV 文件，请按以下方式操作： +为了让 TiDB Cloud 能够访问 Amazon S3 bucket、GCS bucket 或 Azure Blob Storage container 中的 CSV 文件，请按以下方式操作： -- 如果你的 CSV 文件位于 Amazon S3，请[配置 Amazon S3 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 +- 如果你的 CSV 文件位于 Amazon S3，请[配置 Amazon S3 访问](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 - 你可以使用 AWS 访问密钥或 Role ARN 访问你的存储桶。配置完成后，请记录访问密钥（包括访问密钥 ID 和密钥）或 Role ARN 值，后续在 [第 4 步](#step-4-import-csv-files-to-tidb-cloud) 中会用到。 + 你可以使用 AWS 访问密钥或 Role ARN 访问 bucket。完成后，请记录访问密钥（包括 access key ID 和 secret access key）或 Role ARN 值，后续在 [第 4 步](#step-4-import-csv-files-to-tidb-cloud) 中需要用到。 -- 如果你的 CSV 文件位于 GCS，请[配置 GCS 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 +- 如果你的 CSV 文件位于 GCS，请[配置 GCS 访问](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 -- 如果你的 CSV 文件位于 Azure Blob Storage，请[配置 Azure Blob Storage 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 +- 如果你的 CSV 文件位于 Azure Blob Storage，请[配置 Azure Blob Storage 访问](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 ## 第 4 步：将 CSV 文件导入 TiDB Cloud -要将 CSV 文件导入 TiDB Cloud，请按照以下步骤操作： +要将 CSV 文件导入 TiDB Cloud，请按以下步骤操作：
1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > - > 你可以通过左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 选择 **Import data from Cloud Storage**。 @@ -110,28 +110,28 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au - **Included Schema Files**：如果源文件夹包含目标表结构文件（如 `${db_name}-schema-create.sql`），请选择 **Yes**，否则选择 **No**。 - **Data Format**：选择 **CSV**。 - **Edit CSV Configuration**：如有需要，根据你的 CSV 文件配置选项。你可以设置分隔符和定界符字符，指定是否使用反斜杠转义字符，以及文件是否包含表头行。 - - **Folder URI**：输入源文件夹的 URI，格式为 `s3://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`s3://mybucket/myfolder/`。 - - **Bucket Access**：你可以使用 AWS IAM role ARN 或 AWS 访问密钥访问你的存储桶。 - - **AWS Role ARN**（推荐）：输入 AWS IAM role ARN。如果你还没有为存储桶创建 IAM role，可以点击 **Click here to create new one with AWS CloudFormation**，按照屏幕提示使用提供的 AWS CloudFormation 模板创建。你也可以手动为存储桶创建 IAM role ARN。 - - **AWS Access Key**：输入 AWS 访问密钥 ID 和 AWS 密钥。 - - 两种方式的详细说明请参见 [配置 Amazon S3 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 + - **Folder URI**：输入源文件夹 URI，格式为 `s3://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`s3://mybucket/myfolder/`。 + - **Bucket Access**：你可以使用 AWS IAM role ARN 或 AWS 访问密钥访问 bucket。 + - **AWS Role ARN**（推荐）：输入 AWS IAM role ARN 值。如果你还没有为 bucket 创建 IAM role，可以点击 **Click here to create new one with AWS CloudFormation**，按照屏幕上的指引使用提供的 AWS CloudFormation 模板创建。也可以手动为 bucket 创建 IAM role ARN。 + - **AWS Access Key**：输入 AWS access key ID 和 AWS secret access key。 + - 两种方式的详细说明见 [配置 Amazon S3 访问](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 4. 点击 **Connect**。 -5. 在 **Destination** 部分，选择目标数据库和数据表。 +5. 在 **Destination** 部分，选择目标数据库和表。 - 当导入多个文件时，你可以通过 **Advanced Settings** > **Mapping Settings** 自定义每个目标表与其对应 CSV 文件的映射。对于每个目标数据库和表： + 导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义各目标表与其对应 CSV 文件的映射。对于每个目标数据库和表： - **Target Database**：从列表中选择对应的数据库名。 - **Target Table**：从列表中选择对应的表名。 - - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，确保格式为 `s3://[bucket_name]/[data_source_folder]/[file_name].csv`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： + - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，格式为 `s3://[bucket_name]/[data_source_folder]/[file_name].csv`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： - `s3://mybucket/myfolder/my-data1.csv`：`myfolder` 下名为 `my-data1.csv` 的单个 CSV 文件将被导入到目标表。 - `s3://mybucket/myfolder/my-data?.csv`：`myfolder` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.csv` 和 `my-data2.csv`）的 CSV 文件将被导入到同一个目标表。 - `s3://mybucket/myfolder/my-data*.csv`：`myfolder` 下所有以 `my-data` 开头（如 `my-data10.csv` 和 `my-data100.csv`）的 CSV 文件将被导入到同一个目标表。 6. 点击 **Start Import**。 -7. 当导入进度显示 **Completed** 时，检查导入后的数据表。 +7. 当导入进度显示 **Completed** 时，检查已导入的表。
@@ -139,13 +139,13 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > - > 你可以通过左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 选择 **Import data from Cloud Storage**。 @@ -154,25 +154,25 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au - **Included Schema Files**：如果源文件夹包含目标表结构文件（如 `${db_name}-schema-create.sql`），请选择 **Yes**，否则选择 **No**。 - **Data Format**：选择 **CSV**。 - **Edit CSV Configuration**：如有需要，根据你的 CSV 文件配置选项。你可以设置分隔符和定界符字符，指定是否使用反斜杠转义字符，以及文件是否包含表头行。 - - **Folder URI**：输入源文件夹的 URI，格式为 `gs://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`gs://sampledata/ingest/`。 - - **Google Cloud Service Account ID**：TiDB Cloud 会在此页面提供一个唯一的 Service Account ID（如 `example-service-account@your-project.iam.gserviceaccount.com`）。你必须在 Google Cloud 项目中为你的 GCS 存储桶授予该 Service Account ID 必需的 IAM 权限（如 "Storage Object Viewer"）。更多信息请参见 [配置 GCS 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 + - **Folder URI**：输入源文件夹 URI，格式为 `gs://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`gs://sampledata/ingest/`。 + - **Google Cloud Service Account ID**：TiDB Cloud 会在此页面提供一个唯一的 Service Account ID（如 `example-service-account@your-project.iam.gserviceaccount.com`）。你必须在 Google Cloud 项目中为该 Service Account ID 授予必要的 IAM 权限（如 "Storage Object Viewer"）以访问你的 GCS bucket。更多信息见 [配置 GCS 访问](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 4. 点击 **Connect**。 -5. 在 **Destination** 部分，选择目标数据库和数据表。 +5. 在 **Destination** 部分，选择目标数据库和表。 - 当导入多个文件时，你可以通过 **Advanced Settings** > **Mapping Settings** 自定义每个目标表与其对应 CSV 文件的映射。对于每个目标数据库和表： + 导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义各目标表与其对应 CSV 文件的映射。对于每个目标数据库和表： - **Target Database**：从列表中选择对应的数据库名。 - **Target Table**：从列表中选择对应的表名。 - - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，确保格式为 `gs://[bucket_name]/[data_source_folder]/[file_name].csv`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： + - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，格式为 `gs://[bucket_name]/[data_source_folder]/[file_name].csv`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： - `gs://mybucket/myfolder/my-data1.csv`：`myfolder` 下名为 `my-data1.csv` 的单个 CSV 文件将被导入到目标表。 - `gs://mybucket/myfolder/my-data?.csv`：`myfolder` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.csv` 和 `my-data2.csv`）的 CSV 文件将被导入到同一个目标表。 - `gs://mybucket/myfolder/my-data*.csv`：`myfolder` 下所有以 `my-data` 开头（如 `my-data10.csv` 和 `my-data100.csv`）的 CSV 文件将被导入到同一个目标表。 6. 点击 **Start Import**。 -7. 当导入进度显示 **Completed** 时，检查导入后的数据表。 +7. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -180,13 +180,13 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > - > 你可以通过左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 选择 **Import data from Cloud Storage**。 @@ -194,32 +194,52 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au - **Included Schema Files**：如果源文件夹包含目标表结构文件（如 `${db_name}-schema-create.sql`），请选择 **Yes**，否则选择 **No**。 - **Data Format**：选择 **CSV**。 + - **Connectivity Method**：选择 TiDB Cloud 连接 Azure Blob Storage 的方式： + + - **Public**（默认）：通过公网连接。当存储账户允许公网访问时使用此选项。 + - **Private Link**：通过 Azure 私有终端节点进行网络隔离访问。当存储账户禁止公网访问或安全策略要求私有连接时使用此选项。如果选择 **Private Link**，还需填写 **Azure Blob Storage Resource ID**。查找 Resource ID 的方法如下： + + 1. 进入 [Azure portal](https://portal.azure.com/)。 + 2. 导航到你的存储账户，点击 **Overview** > **JSON View**。 + 3. 复制 `id` 属性的值。Resource ID 格式为 `/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`。 + - **Edit CSV Configuration**：如有需要，根据你的 CSV 文件配置选项。你可以设置分隔符和定界符字符，指定是否使用反斜杠转义字符，以及文件是否包含表头行。 - - **Folder URI**：输入存放源文件的 Azure Blob Storage URI，格式为 `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`https://myaccount.blob.core.windows.net/mycontainer/myfolder/`。 - - **SAS Token**：输入账户 SAS token，以允许 TiDB Cloud 访问你 Azure Blob Storage 容器中的源文件。如果你还没有 SAS token，可以点击 **Click here to create a new one with Azure ARM template**，按照屏幕提示使用提供的 Azure ARM 模板创建。你也可以手动创建账户 SAS token。更多信息请参见 [配置 Azure Blob Storage 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 + - **Folder URI**：输入源文件所在的 Azure Blob Storage URI，格式为 `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`https://myaccount.blob.core.windows.net/mycontainer/myfolder/`。 + - **SAS Token**：输入账户 SAS token，以允许 TiDB Cloud 访问 Azure Blob Storage container 中的源文件。如果还没有，可以点击 **Click here to create a new one with Azure ARM template**，按照屏幕上的指引使用提供的 Azure ARM 模板创建。也可以手动创建账户 SAS token。更多信息见 [配置 Azure Blob Storage 访问](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 4. 点击 **Connect**。 -5. 在 **Destination** 部分，选择目标数据库和数据表。 + 如果你选择了 **Private Link** 作为连接方式，TiDB Cloud 会为你的存储账户创建一个私有终端节点。你需要在 Azure portal 中批准该终端节点请求，连接才能继续： + + 1. 进入 [Azure portal](https://portal.azure.com/)，导航到你的存储账户。 + 2. 点击 **Networking** > **Private endpoint connections**。 + 3. 找到来自 TiDB Cloud 的待审批连接请求，点击 **Approve**。 + 4. 返回 [TiDB Cloud 控制台](https://tidbcloud.com/)。终端节点审批通过后，导入向导会自动继续。 + + > **注意：** + > + > 如果终端节点尚未审批，TiDB Cloud 会显示连接待审批的提示。请在 [Azure portal](https://portal.azure.com/) 审批请求后重试连接。 + +5. 在 **Destination** 部分，选择目标数据库和表。 - 当导入多个文件时，你可以通过 **Advanced Settings** > **Mapping Settings** 自定义每个目标表与其对应 CSV 文件的映射。对于每个目标数据库和表： + 导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义各目标表与其对应 CSV 文件的映射。对于每个目标数据库和表： - **Target Database**：从列表中选择对应的数据库名。 - **Target Table**：从列表中选择对应的表名。 - - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，确保格式为 `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].csv`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： + - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，格式为 `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].csv`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： - `https://myaccount.blob.core.windows.net/mycontainer/myfolder/my-data1.csv`：`myfolder` 下名为 `my-data1.csv` 的单个 CSV 文件将被导入到目标表。 - `https://myaccount.blob.core.windows.net/mycontainer/myfolder/my-data?.csv`：`myfolder` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.csv` 和 `my-data2.csv`）的 CSV 文件将被导入到同一个目标表。 - `https://myaccount.blob.core.windows.net/mycontainer/myfolder/my-data*.csv`：`myfolder` 下所有以 `my-data` 开头（如 `my-data10.csv` 和 `my-data100.csv`）的 CSV 文件将被导入到同一个目标表。 6. 点击 **Start Import**。 -7. 当导入进度显示 **Completed** 时，检查导入后的数据表。 +7. 当导入进度显示 **Completed** 时，检查已导入的表。 -当你运行导入任务时，如果检测到任何不支持或无效的类型转换，TiDB Cloud 会自动终止导入作业并报告导入错误。你可以在 **Status** 字段查看详细信息。 +当你运行导入任务时，如果检测到任何不支持或无效的转换，TiDB Cloud 会自动终止导入作业并报告导入错误。你可以在 **Status** 字段查看详细信息。 如果遇到导入错误，请按以下步骤操作： @@ -232,10 +252,10 @@ aliases: ['/tidbcloud/migrate-from-amazon-s3-or-gcs','/tidbcloud/migrate-from-au ### 解决数据导入过程中的警告 -点击 **Start Import** 后，如果看到类似 `can't find the corresponding source files` 的警告信息，请通过提供正确的源文件、根据 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。 +点击 **Start Import** 后，如果看到如 `can't find the corresponding source files` 的警告信息，请通过提供正确的源文件、按 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。 -解决后需要重新导入数据。 +解决后，需要重新导入数据。 -### 导入表中数据行为零 +### 导入表中行数为零 -当导入进度显示 **Completed** 后，检查导入后的数据表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，请通过提供正确的源文件、根据 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后请重新导入这些表。 \ No newline at end of file +当导入进度显示 **Completed** 后，检查已导入的表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，请通过提供正确的源文件、按 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后，重新导入这些表。 \ No newline at end of file diff --git a/tidb-cloud/import-parquet-files-serverless.md b/tidb-cloud/import-parquet-files-serverless.md index 1a328535efd51..ebe978378823f 100644 --- a/tidb-cloud/import-parquet-files-serverless.md +++ b/tidb-cloud/import-parquet-files-serverless.md @@ -7,17 +7,17 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 你可以将未压缩和 Snappy 压缩的 [Apache Parquet](https://parquet.apache.org/) 格式数据文件导入到 TiDB Cloud Starter 或 TiDB Cloud Essential。本文档介绍如何将 Parquet 文件从 Amazon Simple Storage Service（Amazon S3）、Google Cloud Storage（GCS）、Azure Blob Storage 或阿里云对象存储服务（OSS）导入到 TiDB Cloud Starter 或 TiDB Cloud Essential。 -> **Note:** +> **注意：** > -> - 关于 TiDB Cloud Dedicated，请参见 [Import Parquet Files from Cloud Storage into TiDB Cloud Dedicated](/tidb-cloud/import-parquet-files.md)。 -> - TiDB Cloud 仅支持将 Parquet 文件导入到空表中。如果需要将数据导入到已存在数据的表中，可以按照本文档将数据导入到一个临时空表中，然后使用 `INSERT SELECT` 语句将数据复制到目标表。 +> - 关于 TiDB Cloud Dedicated，请参见 [从云存储导入 Parquet 文件到 TiDB Cloud Dedicated](/tidb-cloud/import-parquet-files.md)。 +> - TiDB Cloud 仅支持将 Parquet 文件导入到空表中。如果需要将数据导入到已存在且包含数据的表中，可以按照本文档将数据导入到一个临时空表，然后使用 `INSERT SELECT` 语句将数据复制到目标已存在的表中。 > - Snappy 压缩文件必须采用 [官方 Snappy 格式](https://github.com/google/snappy)。不支持其他变体的 Snappy 压缩格式。 ## 第 1 步：准备 Parquet 文件 -> **Note:** +> **注意：** > -> 目前，TiDB Cloud 不支持导入包含以下任意数据类型的 Parquet 文件。如果待导入的 Parquet 文件包含这些数据类型，你需要先使用 [支持的数据类型](#supported-data-types)（例如 `STRING`）重新生成 Parquet 文件。或者，你也可以使用如 AWS Glue 这样的服务轻松转换数据类型。 +> 当前，TiDB Cloud 不支持导入包含以下任意数据类型的 Parquet 文件。如果待导入的 Parquet 文件包含这些数据类型，你需要先使用 [支持的数据类型](#supported-data-types)（例如 `STRING`）重新生成 Parquet 文件。或者，你也可以使用如 AWS Glue 等服务轻松转换数据类型。 > > - `LIST` > - `NEST STRUCT` @@ -25,34 +25,34 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S > - `ARRAY` > - `MAP` -1. 如果 Parquet 文件大于 256 MB，建议将其拆分为多个小文件，每个文件大小约为 256 MB。 +1. 如果某个 Parquet 文件大于 256 MB，建议将其切分为多个较小的文件，每个文件大小约为 256 MB。 - TiDB Cloud 支持导入非常大的 Parquet 文件，但在多个约 256 MB 的输入文件时性能最佳。这是因为 TiDB Cloud 可以并行处理多个文件，从而大幅提升导入速度。 + TiDB Cloud 支持导入非常大的 Parquet 文件，但在多个约 256 MB 的输入文件并行导入时性能最佳。这是因为 TiDB Cloud 可以并行处理多个文件，从而大幅提升导入速度。 2. 按如下方式命名 Parquet 文件： - - 如果一个 Parquet 文件包含整个表的所有数据，文件名应采用 `${db_name}.${table_name}.parquet` 格式，导入时会映射到 `${db_name}.${table_name}` 表。 - - 如果一个表的数据被拆分到多个 Parquet 文件中，应在这些 Parquet 文件名后添加数字后缀。例如，`${db_name}.${table_name}.000001.parquet` 和 `${db_name}.${table_name}.000002.parquet`。数字后缀可以不连续，但必须递增。同时需要在数字前补零，确保所有后缀长度一致。 + - 如果一个 Parquet 文件包含整个表的所有数据，文件名应采用 `${db_name}.${table_name}.parquet` 格式，导入数据时会映射到 `${db_name}.${table_name}` 表。 + - 如果一个表的数据被分为多个 Parquet 文件，应为这些 Parquet 文件添加数字后缀。例如，`${db_name}.${table_name}.000001.parquet` 和 `${db_name}.${table_name}.000002.parquet`。数字后缀可以不连续，但必须为正序，并且需要在数字前补零以保证所有后缀长度一致。 - > **Note:** + > **注意：** > - > 如果在某些情况下无法按照上述规则修改 Parquet 文件名（例如，Parquet 文件链接也被其他程序使用），可以保持文件名不变，并在 [第 4 步](#step-4-import-parquet-files) 的 **Mapping Settings** 中将源数据导入到单一目标表。 + > 如果在某些情况下无法按照上述规则 update Parquet 文件名（例如，Parquet 文件链接也被其他程序使用），可以保持文件名不变，并在 [第 4 步](#step-4-import-parquet-files) 的 **Mapping Settings** 中将源数据导入到单一目标表。 ## 第 2 步：创建目标表结构 -由于 Parquet 文件不包含表结构信息，在将 Parquet 文件中的数据导入 TiDB Cloud 之前，你需要通过以下任一方式创建表结构： +由于 Parquet 文件不包含 schema 信息，在将 Parquet 文件中的数据导入 TiDB Cloud 之前，你需要通过以下任一方法创建表结构： -- 方法 1：在 TiDB Cloud 中为源数据创建目标数据库和数据表。 +- 方法 1：在 TiDB Cloud 中为源数据创建目标数据库和表。 -- 方法 2：在存放 Parquet 文件的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下，为源数据创建目标表结构文件： +- 方法 2：在存放 Parquet 文件的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下，为源数据创建目标表结构文件，具体如下： 1. 为源数据创建数据库结构文件。 - 如果你的 Parquet 文件遵循 [第 1 步](#step-1-prepare-the-parquet-files) 的命名规则，则数据库结构文件在数据导入时为可选项。否则，数据库结构文件为必需项。 + 如果你的 Parquet 文件遵循 [第 1 步](#step-1-prepare-the-parquet-files) 的命名规则，则数据库结构文件为可选项，否则为必需项。 每个数据库结构文件必须采用 `${db_name}-schema-create.sql` 格式，并包含一个 `CREATE DATABASE` DDL 语句。通过该文件，TiDB Cloud 会在导入数据时创建 `${db_name}` 数据库以存储你的数据。 - 例如，如果你创建了一个包含如下语句的 `mydb-scehma-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 + 例如，如果你创建了一个包含如下语句的 `mydb-schema-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 ```sql CREATE DATABASE mydb; @@ -60,11 +60,11 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 2. 为源数据创建表结构文件。 - 如果你没有在存放 Parquet 文件的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建相应的数据表。 + 如果你未在 Parquet 文件所在的 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建相应的表。 - 每个表结构文件必须采用 `${db_name}.${table_name}-schema.sql` 格式，并包含一个 `CREATE TABLE` DDL 语句。通过该文件，TiDB Cloud 会在 `${db_name}` 数据库中创建 `${db_table}` 表。 + 每个表结构文件必须采用 `${db_name}.${table_name}-schema.sql` 格式，并包含一个 `CREATE TABLE` DDL 语句。通过该文件，TiDB Cloud 会在导入数据时在 `${db_name}` 数据库中创建 `${db_table}` 表。 - 例如，如果你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在 `mydb` 数据库中创建 `mytable` 表。 + 例如，如果你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在导入数据时在 `mydb` 数据库中创建 `mytable` 表。 ```sql CREATE TABLE mytable ( @@ -73,23 +73,23 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S COUNT INT ); ``` - > **Note:** + > **注意：** > - > 每个 `${db_name}.${table_name}-schema.sql` 文件只能包含一个 DDL 语句。如果文件中包含多个 DDL 语句，只有第一个会生效。 + > 每个 `${db_name}.${table_name}-schema.sql` 文件只能包含一个 DDL 语句。如果文件中包含多个 DDL 语句，仅第一个生效。 -## 第 3 步：配置跨账号访问 +## 第 3 步：配置跨账户访问 -为了让 TiDB Cloud 能够访问 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务桶中的 Parquet 文件，请执行以下操作之一： +为了让 TiDB Cloud 能够访问 Amazon S3、GCS、Azure Blob Storage 或阿里云对象存储服务 bucket 中的 Parquet 文件，请执行以下操作之一： -- 如果你的 Parquet 文件位于 Amazon S3，请为集群 [配置 Amazon S3 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- 如果你的 Parquet 文件位于 Amazon S3，请为你的集群 [配置 Amazon S3 访问](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 - 你可以使用 AWS 访问密钥或 Role ARN 访问你的桶。完成后，请记录访问密钥（包括访问密钥 ID 和密钥）或 Role ARN 值，在 [第 4 步](#step-4-import-parquet-files) 中会用到。 + 你可以使用 AWS access key 或 Role ARN 访问 bucket。完成后，请记录 access key（包括 access key ID 和 secret access key）或 Role ARN 值，后续在 [第 4 步](#step-4-import-parquet-files) 中需要用到。 -- 如果你的 Parquet 文件位于 GCS，请为集群 [配置 GCS 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 +- 如果你的 Parquet 文件位于 GCS，请为你的集群 [配置 GCS 访问](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 -- 如果你的 Parquet 文件位于 Azure Blob Storage，请为集群 [配置 Azure Blob Storage 访问权限](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 +- 如果你的 Parquet 文件位于 Azure Blob Storage，请为你的集群 [配置 Azure Blob Storage 访问](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 -- 如果你的 Parquet 文件位于阿里云对象存储服务（OSS），请为集群 [配置阿里云对象存储服务（OSS）访问权限](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- 如果你的 Parquet 文件位于阿里云对象存储服务（OSS），请为你的集群 [配置阿里云对象存储服务（OSS）访问](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 ## 第 4 步：导入 Parquet 文件 @@ -100,13 +100,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -116,9 +116,9 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Source Files URI**： - 导入单个文件时，输入源文件 URI，格式为 `s3://[bucket_name]/[data_source_folder]/[file_name].parquet`。例如：`s3://sampledata/ingest/TableName.01.parquet`。 - 导入多个文件时，输入源文件夹 URI，格式为 `s3://[bucket_name]/[data_source_folder]/`。例如：`s3://sampledata/ingest/`。 - - **Credential**：你可以使用 AWS Role ARN 或 AWS 访问密钥访问你的桶。更多信息请参见 [Configure Amazon S3 access](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 + - **Credential**：你可以使用 AWS Role ARN 或 AWS access key 访问 bucket。详情参见 [配置 Amazon S3 访问](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 - **AWS Role ARN**：输入 AWS Role ARN 值。 - - **AWS Access Key**：输入 AWS 访问密钥 ID 和 AWS 密钥。 + - **AWS Access Key**：输入 AWS access key ID 和 AWS secret access key。 4. 点击 **Next**。 @@ -126,13 +126,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表进行数据导入。 - - 若希望 TiDB Cloud 自动将所有遵循 [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 + - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 - - 若需手动配置映射规则，将源 Parquet 文件与目标数据库和表关联，请取消选中该选项，然后填写以下字段： + - 若需手动配置映射规则，将你的源 Parquet 文件与目标数据库和表关联，请取消选中该选项，并填写以下字段： - **Source**：输入 `[file_name].parquet` 格式的文件名模式。例如：`TableName.01.parquet`。你也可以使用通配符匹配多个文件，仅支持 `*` 和 `?` 通配符。 @@ -141,9 +141,9 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Target Database** 和 **Target Table**：选择要导入数据的目标数据库和表。 -6. 点击 **Next**。TiDB Cloud 会相应地扫描源文件。 +6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审查扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 8. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -153,13 +153,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -169,7 +169,7 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Source Files URI**： - 导入单个文件时，输入源文件 URI，格式为 `[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].parquet`。例如：`[gcs|gs]://sampledata/ingest/TableName.01.parquet`。 - 导入多个文件时，输入源文件夹 URI，格式为 `[gcs|gs]://[bucket_name]/[data_source_folder]/`。例如：`[gcs|gs]://sampledata/ingest/`。 - - **Credential**：你可以使用 GCS IAM Role Service Account key 访问你的桶。更多信息请参见 [Configure GCS access](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 + - **Credential**：你可以使用 GCS IAM Role Service Account key 访问 bucket。详情参见 [配置 GCS 访问](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 4. 点击 **Next**。 @@ -177,13 +177,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表进行数据导入。 - - 若希望 TiDB Cloud 自动将所有遵循 [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 + - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 - - 若需手动配置映射规则，将源 Parquet 文件与目标数据库和表关联，请取消选中该选项，然后填写以下字段： + - 若需手动配置映射规则，将你的源 Parquet 文件与目标数据库和表关联，请取消选中该选项，并填写以下字段： - **Source**：输入 `[file_name].parquet` 格式的文件名模式。例如：`TableName.01.parquet`。你也可以使用通配符匹配多个文件，仅支持 `*` 和 `?` 通配符。 @@ -192,9 +192,9 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Target Database** 和 **Target Table**：选择要导入数据的目标数据库和表。 -6. 点击 **Next**。TiDB Cloud 会相应地扫描源文件。 +6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审查扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 8. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -204,13 +204,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -220,7 +220,7 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Source Files URI**： - 导入单个文件时，输入源文件 URI，格式为 `[azure|https]://[bucket_name]/[data_source_folder]/[file_name].parquet`。例如：`[azure|https]://sampledata/ingest/TableName.01.parquet`。 - 导入多个文件时，输入源文件夹 URI，格式为 `[azure|https]://[bucket_name]/[data_source_folder]/`。例如：`[azure|https]://sampledata/ingest/`。 - - **Credential**：你可以使用共享访问签名（SAS）令牌访问你的桶。更多信息请参见 [Configure Azure Blob Storage access](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 + - **Credential**：你可以使用共享访问签名（SAS）token 访问 bucket。详情参见 [配置 Azure Blob Storage 访问](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 4. 点击 **Next**。 @@ -228,13 +228,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表进行数据导入。 - - 若希望 TiDB Cloud 自动将所有遵循 [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 + - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 - - 若需手动配置映射规则，将源 Parquet 文件与目标数据库和表关联，请取消选中该选项，然后填写以下字段： + - 若需手动配置映射规则，将你的源 Parquet 文件与目标数据库和表关联，请取消选中该选项，并填写以下字段： - **Source**：输入 `[file_name].parquet` 格式的文件名模式。例如：`TableName.01.parquet`。你也可以使用通配符匹配多个文件，仅支持 `*` 和 `?` 通配符。 @@ -243,9 +243,9 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Target Database** 和 **Target Table**：选择要导入数据的目标数据库和表。 -6. 点击 **Next**。TiDB Cloud 会相应地扫描源文件。 +6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审查扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 8. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -255,13 +255,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 1. 打开目标集群的 **Import** 页面。 - 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + 1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 - > **Tip:** + > **提示：** > > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 - 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 + 2. 点击目标集群名称进入其概览页面，然后在左侧导航栏点击 **Data** > **Import**。 2. 点击 **Import data from Cloud Storage**。 @@ -271,7 +271,7 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Source Files URI**： - 导入单个文件时，输入源文件 URI，格式为 `oss://[bucket_name]/[data_source_folder]/[file_name].parquet`。例如：`oss://sampledata/ingest/TableName.01.parquet`。 - 导入多个文件时，输入源文件夹 URI，格式为 `oss://[bucket_name]/[data_source_folder]/`。例如：`oss://sampledata/ingest/`。 - - **Credential**：你可以使用 AccessKey 对访问你的桶。更多信息请参见 [Configure Alibaba Cloud Object Storage Service (OSS) access](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 + - **Credential**：你可以使用 AccessKey 对访问 bucket。详情参见 [配置阿里云对象存储服务（OSS）访问](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 4. 点击 **Next**。 @@ -279,13 +279,13 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S 当 **Source Files URI** 指定为目录时，**Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项默认被选中。 - > **Note:** + > **注意：** > > 当 **Source Files URI** 指定为单个文件时，不显示 **Use [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) for automatic mapping** 选项，TiDB Cloud 会自动将 **Source** 字段填充为文件名。此时你只需选择目标数据库和表进行数据导入。 - - 若希望 TiDB Cloud 自动将所有遵循 [File naming conventions](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 + - 若希望 TiDB Cloud 自动将所有遵循 [文件命名规范](/tidb-cloud/naming-conventions-for-data-import.md) 的源文件映射到对应表，请保持该选项选中，并选择 **Parquet** 作为数据格式。 - - 若需手动配置映射规则，将源 Parquet 文件与目标数据库和表关联，请取消选中该选项，然后填写以下字段： + - 若需手动配置映射规则，将你的源 Parquet 文件与目标数据库和表关联，请取消选中该选项，并填写以下字段： - **Source**：输入 `[file_name].parquet` 格式的文件名模式。例如：`TableName.01.parquet`。你也可以使用通配符匹配多个文件，仅支持 `*` 和 `?` 通配符。 @@ -294,9 +294,9 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S - **Target Database** 和 **Target Table**：选择要导入数据的目标数据库和表。 -6. 点击 **Next**。TiDB Cloud 会相应地扫描源文件。 +6. 点击 **Next**。TiDB Cloud 会相应扫描源文件。 -7. 审查扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 +7. 审核扫描结果，检查找到的数据文件及其对应的目标表，然后点击 **Start Import**。 8. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -304,12 +304,12 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S -当你运行导入任务时，如果检测到任何不支持或无效的类型转换，TiDB Cloud 会自动终止导入作业并报告导入错误。 +当你运行导入任务时，如果检测到任何不支持或无效的转换，TiDB Cloud 会自动终止导入作业并报告导入错误。 -如果你遇到导入错误，请按以下步骤操作： +如果遇到导入错误，请按以下步骤操作： 1. 删除部分导入的表。 -2. 检查表结构文件，如有错误请修正。 +2. 检查表结构文件，如有错误请修正表结构文件。 3. 检查 Parquet 文件中的数据类型。 如果 Parquet 文件包含任何不支持的数据类型（如 `NEST STRUCT`、`ARRAY` 或 `MAP`），你需要使用 [支持的数据类型](#supported-data-types)（如 `STRING`）重新生成 Parquet 文件。 @@ -341,10 +341,10 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS、Azure Blob S ### 解决数据导入过程中的警告 -点击 **Start Import** 后，如果看到类似 `can't find the corresponding source files` 的警告信息，请通过提供正确的源文件、根据 [Naming Conventions for Data Import](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。 +点击 **Start Import** 后，如果看到类似 `can't find the corresponding source files` 的警告信息，可以通过提供正确的源文件、按照 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md)重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。 解决这些问题后，需要重新导入数据。 ### 导入表中行数为零 -当导入进度显示 **Completed** 后，检查已导入的表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，请通过提供正确的源文件、根据 [Naming Conventions for Data Import](/tidb-cloud/naming-conventions-for-data-import.md) 重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后，重新导入这些表。 \ No newline at end of file +当导入进度显示 **Completed** 后，检查已导入的表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，请通过提供正确的源文件、按照 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md)重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后，重新导入这些表。 \ No newline at end of file diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index 3ed8dde3774e9..988f1ad51cad1 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -1,23 +1,23 @@ --- -title: 从云存储导入 Apache Parquet 文件到 TiDB Cloud Dedicated 集群 -summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob Storage 导入到 TiDB Cloud Dedicated 集群。 +title: 从云存储导入 Apache Parquet 文件到 TiDB Cloud Dedicated +summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob Storage 导入到 TiDB Cloud Dedicated。 --- -# 从云存储导入 Apache Parquet 文件到 TiDB Cloud Dedicated 集群 +# 从云存储导入 Apache Parquet 文件到 TiDB Cloud Dedicated -本文档介绍如何将 Apache Parquet 文件从 Amazon Simple Storage Service（Amazon S3）、Google Cloud Storage（GCS）或 Azure Blob Storage 导入到 TiDB Cloud Dedicated 集群。你可以导入未压缩的 Parquet 文件或使用 [Google Snappy](https://github.com/google/snappy) 压缩的 Parquet 文件。不支持其他 Parquet 压缩编解码器。 +本文档介绍如何将 Apache Parquet 文件从 Amazon Simple Storage Service（Amazon S3）、Google Cloud Storage（GCS）或 Azure Blob Storage 导入到 TiDB Cloud Dedicated。你可以导入未压缩的 Parquet 文件，或使用 [Google Snappy](https://github.com/google/snappy) 压缩的 Parquet 文件。不支持其他 Parquet 压缩编码。 ## 限制 -- 为确保数据一致性，TiDB Cloud 仅允许将 Parquet 文件导入到空表中。若需将数据导入到已存在数据的表中，你可以按照本文档的步骤，先将数据导入到一个临时空表中，然后使用 `INSERT SELECT` 语句将数据复制到目标表。 +- 为保证数据一致性，TiDB Cloud 仅允许将 Parquet 文件导入到空表中。若需将数据导入已存在数据的表，可以按照本文档的方式，先将数据导入到一个临时空表，然后使用 `INSERT SELECT` 语句将数据复制到目标已存在的表中。 -- 如果 TiDB Cloud Dedicated 集群已开启 [changefeed](/tidb-cloud/changefeed-overview.md) 或 [时间点恢复](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)，则无法向该集群导入数据（**Import Data** 按钮会被禁用），因为当前数据导入功能使用的是 [物理导入模式](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)。在该模式下，导入的数据不会生成变更日志，因此 changefeed 和时间点恢复无法检测到导入的数据。 +- 如果 TiDB Cloud Dedicated 集群已开启 [changefeed](/tidb-cloud/changefeed-overview.md) 或已启用 [Point-in-time Restore](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)，则无法向该集群导入数据（**Import Data** 按钮会被禁用），因为当前数据导入功能使用的是 [物理导入模式](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)。在该模式下，导入的数据不会生成变更日志，因此 changefeed 和 Point-in-time Restore 无法检测到导入的数据。 ## 第 1 步：准备 Parquet 文件 > **注意：** > -> 目前，TiDB Cloud 不支持导入包含以下任意数据类型的 Parquet 文件。如果待导入的 Parquet 文件包含这些数据类型，你需要先使用 [支持的数据类型](#supported-data-types)（例如 `STRING`）重新生成 Parquet 文件。或者，你也可以使用如 AWS Glue 等服务轻松转换数据类型。 +> 当前，TiDB Cloud 不支持导入包含以下任意数据类型的 Parquet 文件。如果待导入的 Parquet 文件包含这些数据类型，你需要先使用 [支持的数据类型](#supported-data-types)（例如 `STRING`）重新生成 Parquet 文件。或者，你也可以使用 AWS Glue 等服务轻松转换数据类型。 > > - `LIST` > - `NEST STRUCT` @@ -25,35 +25,35 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob > - `ARRAY` > - `MAP` -1. 如果单个 Parquet 文件大于 256 MB，建议将其拆分为多个小文件，每个文件大小约为 256 MB。 +1. 如果某个 Parquet 文件大于 256 MB，建议将其切分为更小的文件，每个文件大小约为 256 MB。 - TiDB Cloud 支持导入非常大的 Parquet 文件，但在多个约 256 MB 的输入文件时性能最佳。这是因为 TiDB Cloud 可以并行处理多个文件，从而大幅提升导入速度。 + TiDB Cloud 支持导入非常大的 Parquet 文件，但在输入文件大小约为 256 MB 且数量较多时性能最佳。这是因为 TiDB Cloud 可以并行处理多个文件，从而大幅提升导入速度。 2. 按如下方式命名 Parquet 文件： - 如果一个 Parquet 文件包含整个表的所有数据，文件名应采用 `${db_name}.${table_name}.parquet` 格式，导入时会映射到 `${db_name}.${table_name}` 表。 - - 如果一个表的数据被拆分为多个 Parquet 文件，应为这些文件添加数字后缀。例如，`${db_name}.${table_name}.000001.parquet` 和 `${db_name}.${table_name}.000002.parquet`。数字后缀可以不连续，但必须递增，并且需要在数字前补零以保证所有后缀长度一致。 + - 如果一个表的数据被分为多个 Parquet 文件，应为这些文件添加数字后缀。例如，`${db_name}.${table_name}.000001.parquet` 和 `${db_name}.${table_name}.000002.parquet`。数字后缀可以不连续，但必须为正序，并且需要在数字前补零以保证所有后缀长度一致。 > **注意：** > - > - 如果在某些情况下无法按照上述规则修改 Parquet 文件名（例如，Parquet 文件链接也被其他程序使用），你可以保持文件名不变，并在 [第 4 步](#step-4-import-parquet-files-to-tidb-cloud) 的 **Mapping Settings** 中将源数据导入到单一目标表。 - > - Snappy 压缩文件必须采用 [官方 Snappy 格式](https://github.com/google/snappy)。不支持其他 Snappy 压缩变体。 + > - 如果在某些场景下无法按照上述规则修改 Parquet 文件名（例如这些 Parquet 文件链接也被其他程序使用），可以保持文件名不变，并在 [第 4 步](#step-4-import-parquet-files-to-tidb-cloud) 的 **Mapping Settings** 中将源数据导入到单个目标表。 + > - Snappy 压缩文件必须为 [官方 Snappy 格式](https://github.com/google/snappy)。不支持其他 Snappy 压缩变体。 ## 第 2 步：创建目标表结构 -由于 Parquet 文件不包含表结构信息，在将 Parquet 文件中的数据导入 TiDB Cloud 之前，你需要通过以下任一方式创建表结构： +由于 Parquet 文件不包含 schema 信息，在将 Parquet 文件中的数据导入 TiDB Cloud 之前，你需要通过以下任一方法创建表结构： -- 方法一：在 TiDB Cloud 中为源数据创建目标数据库和数据表。 +- 方法 1：在 TiDB Cloud 中为源数据创建目标数据库和表。 -- 方法二：在存放 Parquet 文件的 Amazon S3、GCS 或 Azure Blob Storage 目录下，为源数据创建目标表结构文件，具体如下： +- 方法 2：在存放 Parquet 文件的 Amazon S3、GCS 或 Azure Blob Storage 目录下，为源数据创建目标表结构文件，具体如下： 1. 为源数据创建数据库结构文件。 - 如果你的 Parquet 文件遵循 [第 1 步](#step-1-prepare-the-parquet-files) 的命名规则，则数据库结构文件为可选项，否则为必需项。 + 如果你的 Parquet 文件遵循 [第 1 步](#step-1-prepare-the-parquet-files) 的命名规则，则数据库结构文件对于数据导入来说是可选的。否则，数据库结构文件是必需的。 每个数据库结构文件必须采用 `${db_name}-schema-create.sql` 格式，并包含一个 `CREATE DATABASE` DDL 语句。通过该文件，TiDB Cloud 会在导入数据时创建 `${db_name}` 数据库以存储你的数据。 - 例如，如果你创建了一个包含如下语句的 `mydb-scehma-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 + 例如，如果你创建了一个包含如下语句的 `mydb-schema-create.sql` 文件，TiDB Cloud 会在导入数据时创建 `mydb` 数据库。 ```sql @@ -62,11 +62,11 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob 2. 为源数据创建表结构文件。 - 如果你未在 Parquet 文件所在的 Amazon S3、GCS 或 Azure Blob Storage 目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建相应的数据表。 + 如果你没有在 Parquet 文件所在的 Amazon S3、GCS 或 Azure Blob Storage 目录下包含表结构文件，TiDB Cloud 在导入数据时不会为你创建对应的表。 - 每个表结构文件必须采用 `${db_name}.${table_name}-schema.sql` 格式，并包含一个 `CREATE TABLE` DDL 语句。通过该文件，TiDB Cloud 会在导入数据时于 `${db_name}` 数据库中创建 `${db_table}` 表。 + 每个表结构文件必须采用 `${db_name}.${table_name}-schema.sql` 格式，并包含一个 `CREATE TABLE` DDL 语句。通过该文件，TiDB Cloud 会在 `${db_name}` 数据库中创建 `${db_table}` 表以存储你的数据。 - 例如，如果你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在 `mydb` 数据库中创建 `mytable` 表。 + 例如，如果你创建了一个包含如下语句的 `mydb.mytable-schema.sql` 文件，TiDB Cloud 会在导入数据时在 `mydb` 数据库中创建 `mytable` 表。 ```sql @@ -78,19 +78,19 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob > **注意：** > - > 每个 `${db_name}.${table_name}-schema.sql` 文件只能包含一个 DDL 语句。如果文件中包含多个 DDL 语句，仅第一个生效。 + > 每个 `${db_name}.${table_name}-schema.sql` 文件只能包含一个 DDL 语句。如果文件中包含多个 DDL 语句，只有第一个会生效。 -## 第 3 步：配置跨账号访问 +## 第 3 步：配置跨账户访问 -为了让 TiDB Cloud 能够访问 Amazon S3、GCS 或 Azure Blob Storage 中的 Parquet 文件，请按以下方式操作： +为了让 TiDB Cloud 能够访问 Amazon S3 bucket、GCS bucket 或 Azure Blob Storage container 中的 Parquet 文件，请按以下方式操作： -- 如果 Parquet 文件位于 Amazon S3，[配置 Amazon S3 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 +- 如果你的 Parquet 文件位于 Amazon S3，[配置 Amazon S3 访问](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 - 你可以使用 AWS 访问密钥或 Role ARN 访问你的存储桶。完成后，请记录访问密钥（包括访问密钥 ID 和密钥）或 Role ARN 值，后续在 [第 4 步](#step-4-import-parquet-files-to-tidb-cloud) 中会用到。 + 你可以使用 AWS 访问密钥或 Role ARN 访问 bucket。完成后，请记录访问密钥（包括 access key ID 和 secret access key）或 Role ARN 值，后续在 [第 4 步](#step-4-import-parquet-files-to-tidb-cloud) 中需要用到。 -- 如果 Parquet 文件位于 GCS，[配置 GCS 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 +- 如果你的 Parquet 文件位于 GCS，[配置 GCS 访问](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 -- 如果 Parquet 文件位于 Azure Blob Storage，[配置 Azure Blob Storage 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 +- 如果你的 Parquet 文件位于 Azure Blob Storage，[配置 Azure Blob Storage 访问](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 ## 第 4 步：将 Parquet 文件导入 TiDB Cloud @@ -105,7 +105,7 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob > **提示：** > - > 你可以使用左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 @@ -115,28 +115,28 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob - **Included Schema Files**：如果源文件夹包含目标表结构文件（如 `${db_name}-schema-create.sql`），请选择 **Yes**，否则选择 **No**。 - **Data Format**：选择 **Parquet**。 - - **Folder URI**：输入源文件夹的 URI，格式为 `s3://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`s3://sampledata/ingest/`。 - - **Bucket Access**：你可以使用 AWS IAM Role ARN 或 AWS 访问密钥访问存储桶。 - - **AWS Role ARN**（推荐）：输入 AWS IAM Role ARN。如果还没有为存储桶创建 IAM 角色，可以点击 **Click here to create new one with AWS CloudFormation**，按照屏幕提示使用提供的 AWS CloudFormation 模板创建。也可以手动为存储桶创建 IAM Role ARN。 - - **AWS Access Key**：输入 AWS 访问密钥 ID 和 AWS 密钥。 - - 两种方式的详细说明见 [配置 Amazon S3 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 + - **Folder URI**：输入源文件夹 URI，格式为 `s3://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`s3://sampledata/ingest/`。 + - **Bucket Access**：你可以使用 AWS IAM role ARN 或 AWS 访问密钥访问 bucket。 + - **AWS Role ARN**（推荐）：输入 AWS IAM role ARN。如果还没有为 bucket 创建 IAM role，可以点击 **Click here to create new one with AWS CloudFormation**，按照屏幕上的指引使用提供的 AWS CloudFormation 模板创建。也可以手动为 bucket 创建 IAM role ARN。 + - **AWS Access Key**：输入 AWS access key ID 和 AWS secret access key。 + - 两种方式的详细说明见 [配置 Amazon S3 访问](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 4. 点击 **Connect**。 -5. 在 **Destination** 部分，选择目标数据库和数据表。 +5. 在 **Destination** 部分，选择目标数据库和表。 - 当导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义每个目标表与其对应 Parquet 文件的映射。对于每个目标数据库和表： + 导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义各目标表与其对应 Parquet 文件的映射。对于每个目标数据库和表： - **Target Database**：从列表中选择对应的数据库名。 - **Target Table**：从列表中选择对应的表名。 - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，格式为 `s3://[bucket_name]/[data_source_folder]/[file_name].parquet`。例如，`s3://sampledata/ingest/TableName.01.parquet`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： - - `s3://[bucket_name]/[data_source_folder]/my-data1.parquet`：将 `[data_source_folder]` 下名为 `my-data1.parquet` 的单个 Parquet 文件导入目标表。 - - `s3://[bucket_name]/[data_source_folder]/my-data?.parquet`：将 `[data_source_folder]` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.parquet` 和 `my-data2.parquet`）的 Parquet 文件导入同一目标表。 - - `s3://[bucket_name]/[data_source_folder]/my-data*.parquet`：将 `[data_source_folder]` 下所有以 `my-data` 开头（如 `my-data10.parquet` 和 `my-data100.parquet`）的 Parquet 文件导入同一目标表。 + - `s3://[bucket_name]/[data_source_folder]/my-data1.parquet`：`[data_source_folder]` 下名为 `my-data1.parquet` 的单个 Parquet 文件将被导入到目标表。 + - `s3://[bucket_name]/[data_source_folder]/my-data?.parquet`：`[data_source_folder]` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.parquet` 和 `my-data2.parquet`）的 Parquet 文件将被导入到同一个目标表。 + - `s3://[bucket_name]/[data_source_folder]/my-data*.parquet`：`[data_source_folder]` 下所有以 `my-data` 开头（如 `my-data10.parquet` 和 `my-data100.parquet`）的 Parquet 文件将被导入到同一个目标表。 6. 点击 **Start Import**。 -7. 当导入进度显示 **Completed** 时，检查已导入的数据表。 +7. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -148,7 +148,7 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob > **提示：** > - > 你可以使用左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 @@ -158,25 +158,25 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob - **Included Schema Files**：如果源文件夹包含目标表结构文件（如 `${db_name}-schema-create.sql`），请选择 **Yes**，否则选择 **No**。 - **Data Format**：选择 **Parquet**。 - - **Folder URI**：输入源文件夹的 URI，格式为 `gs://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`gs://sampledata/ingest/`。 - - **Google Cloud Service Account ID**：TiDB Cloud 会在此页面提供一个唯一的 Service Account ID（如 `example-service-account@your-project.iam.gserviceaccount.com`）。你必须在 Google Cloud 项目中为该 Service Account ID 授予所需的 IAM 权限（如 “Storage Object Viewer”）以访问你的 GCS 存储桶。更多信息见 [配置 GCS 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 + - **Folder URI**：输入源文件夹 URI，格式为 `gs://[bucket_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`gs://sampledata/ingest/`。 + - **Google Cloud Service Account ID**：TiDB Cloud 会在此页面提供一个唯一的 Service Account ID（如 `example-service-account@your-project.iam.gserviceaccount.com`）。你必须在 Google Cloud 项目中为该 Service Account ID 授予必要的 IAM 权限（如 “Storage Object Viewer”）以访问你的 GCS bucket。更多信息见 [配置 GCS 访问](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 4. 点击 **Connect**。 -5. 在 **Destination** 部分，选择目标数据库和数据表。 +5. 在 **Destination** 部分，选择目标数据库和表。 - 当导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义每个目标表与其对应 Parquet 文件的映射。对于每个目标数据库和表： + 导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义各目标表与其对应 Parquet 文件的映射。对于每个目标数据库和表： - **Target Database**：从列表中选择对应的数据库名。 - **Target Table**：从列表中选择对应的表名。 - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，格式为 `gs://[bucket_name]/[data_source_folder]/[file_name].parquet`。例如，`gs://sampledata/ingest/TableName.01.parquet`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： - - `gs://[bucket_name]/[data_source_folder]/my-data1.parquet`：将 `[data_source_folder]` 下名为 `my-data1.parquet` 的单个 Parquet 文件导入目标表。 - - `gs://[bucket_name]/[data_source_folder]/my-data?.parquet`：将 `[data_source_folder]` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.parquet` 和 `my-data2.parquet`）的 Parquet 文件导入同一目标表。 - - `gs://[bucket_name]/[data_source_folder]/my-data*.parquet`：将 `[data_source_folder]` 下所有以 `my-data` 开头（如 `my-data10.parquet` 和 `my-data100.parquet`）的 Parquet 文件导入同一目标表。 + - `gs://[bucket_name]/[data_source_folder]/my-data1.parquet`：`[data_source_folder]` 下名为 `my-data1.parquet` 的单个 Parquet 文件将被导入到目标表。 + - `gs://[bucket_name]/[data_source_folder]/my-data?.parquet`：`[data_source_folder]` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.parquet` 和 `my-data2.parquet`）的 Parquet 文件将被导入到同一个目标表。 + - `gs://[bucket_name]/[data_source_folder]/my-data*.parquet`：`[data_source_folder]` 下所有以 `my-data` 开头（如 `my-data10.parquet` 和 `my-data100.parquet`）的 Parquet 文件将被导入到同一个目标表。 6. 点击 **Start Import**。 -7. 当导入进度显示 **Completed** 时，检查已导入的数据表。 +7. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -188,7 +188,7 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob > **提示：** > - > 你可以使用左上角的下拉框切换组织、项目和集群。 + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Data** > **Import**。 @@ -198,25 +198,45 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob - **Included Schema Files**：如果源文件夹包含目标表结构文件（如 `${db_name}-schema-create.sql`），请选择 **Yes**，否则选择 **No**。 - **Data Format**：选择 **Parquet**。 - - **Folder URI**：输入源文件所在的 Azure Blob Storage URI，格式为 `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`https://myaccount.blob.core.windows.net/mycontainer/data-ingestion/`。 - - **SAS Token**：输入账户 SAS token，以允许 TiDB Cloud 访问 Azure Blob Storage 容器中的源文件。如果还没有 SAS token，可以点击 **Click here to create a new one with Azure ARM template**，按照屏幕提示使用提供的 Azure ARM 模板创建。也可以手动创建账户 SAS token。更多信息见 [配置 Azure Blob Storage 访问权限](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 + - **Connectivity Method**：选择 TiDB Cloud 连接 Azure Blob Storage 的方式： + + - **Public**（默认）：通过公网连接。当存储账户允许公网访问时使用此选项。 + - **Private Link**：通过 Azure 私有终端节点进行网络隔离访问。当存储账户禁止公网访问或安全策略要求私有连接时使用此选项。如果选择 **Private Link**，还需填写 **Azure Blob Storage Resource ID**。查找 resource ID 的方法如下： + + 1. 进入 [Azure 门户](https://portal.azure.com/)。 + 2. 导航到你的存储账户，点击 **Overview** > **JSON View**。 + 3. 复制 `id` 属性的值。resource ID 格式为 `/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`。 + + - **Folder URI**：输入 Azure Blob Storage 中源文件所在的 URI，格式为 `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`，路径必须以 `/` 结尾。例如，`https://myaccount.blob.core.windows.net/mycontainer/data-ingestion/`。 + - **SAS Token**：输入账户 SAS token，以允许 TiDB Cloud 访问 Azure Blob Storage container 中的源文件。如果还没有，可以点击 **Click here to create a new one with Azure ARM template**，按照屏幕上的指引使用 Azure ARM 模板创建。也可以手动创建账户 SAS token。更多信息见 [配置 Azure Blob Storage 访问](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 4. 点击 **Connect**。 -5. 在 **Destination** 部分，选择目标数据库和数据表。 + 如果你选择了 **Private Link** 作为连接方式，TiDB Cloud 会为你的存储账户创建一个私有终端节点。你需要在 Azure 门户中批准该终端节点请求，连接才能继续： + + 1. 进入 [Azure 门户](https://portal.azure.com/)，导航到你的存储账户。 + 2. 点击 **Networking** > **Private endpoint connections**。 + 3. 找到来自 TiDB Cloud 的待审批连接请求，点击 **Approve**。 + 4. 返回 [TiDB Cloud 控制台](https://tidbcloud.com/)。终端节点批准后，导入向导会自动继续。 + + > **注意：** + > + > 如果终端节点尚未批准，TiDB Cloud 会显示连接待审批的提示。请在 [Azure 门户](https://portal.azure.com/) 批准请求后重试连接。 + +5. 在 **Destination** 部分，选择目标数据库和表。 - 当导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义每个目标表与其对应 Parquet 文件的映射。对于每个目标数据库和表： + 导入多个文件时，可以通过 **Advanced Settings** > **Mapping Settings** 自定义各目标表与其对应 Parquet 文件的映射。对于每个目标数据库和表： - **Target Database**：从列表中选择对应的数据库名。 - **Target Table**：从列表中选择对应的表名。 - **Source File URIs and Names**：输入源文件的完整 URI，包括文件夹和文件名，格式为 `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].parquet`。例如，`https://myaccount.blob.core.windows.net/mycontainer/data-ingestion/TableName.01.parquet`。你也可以使用通配符（`?` 和 `*`）匹配多个文件。例如： - - `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/my-data1.parquet`：将 `[data_source_folder]` 下名为 `my-data1.parquet` 的单个 Parquet 文件导入目标表。 - - `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/my-data?.parquet`：将 `[data_source_folder]` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.parquet` 和 `my-data2.parquet`）的 Parquet 文件导入同一目标表。 - - `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/my-data*.parquet`：将 `[data_source_folder]` 下所有以 `my-data` 开头（如 `my-data10.parquet` 和 `my-data100.parquet`）的 Parquet 文件导入同一目标表。 + - `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/my-data1.parquet`：`[data_source_folder]` 下名为 `my-data1.parquet` 的单个 Parquet 文件将被导入到目标表。 + - `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/my-data?.parquet`：`[data_source_folder]` 下所有以 `my-data` 开头、后跟一个字符（如 `my-data1.parquet` 和 `my-data2.parquet`）的 Parquet 文件将被导入到同一个目标表。 + - `https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/my-data*.parquet`：`[data_source_folder]` 下所有以 `my-data` 开头（如 `my-data10.parquet` 和 `my-data100.parquet`）的 Parquet 文件将被导入到同一个目标表。 6. 点击 **Start Import**。 -7. 当导入进度显示 **Completed** 时，检查已导入的数据表。 +7. 当导入进度显示 **Completed** 时，检查已导入的表。 @@ -261,8 +281,8 @@ summary: 了解如何将 Apache Parquet 文件从 Amazon S3、GCS 或 Azure Blob 点击 **Start Import** 后，如果看到类似 `can't find the corresponding source files` 的警告信息，可以通过提供正确的源文件、按照 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md)重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。 -解决后需要重新导入数据。 +解决这些问题后，需要重新导入数据。 -### 导入表中数据行为零 +### 导入表中行数为零 -导入进度显示 **Completed** 后，检查已导入的数据表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，可以通过提供正确的源文件、按照 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md)重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后请重新导入这些表。 \ No newline at end of file +当导入进度显示 **Completed** 后，检查已导入的表。如果行数为零，说明没有数据文件匹配你输入的 Bucket URI。此时，可以通过提供正确的源文件、按照 [数据导入命名规范](/tidb-cloud/naming-conventions-for-data-import.md)重命名现有文件，或使用 **Advanced Settings** 进行调整来解决。之后，重新导入这些表。 \ No newline at end of file diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index 55a01bb1a57ff..47449a55bb436 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -11,7 +11,7 @@ TiDB Cloud 为你提供了便捷的方式来查看告警、编辑告警规则， > **注意：** > -> 目前，告警订阅仅适用于 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 和 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 +> 目前，告警订阅功能适用于 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 和 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 ## 查看告警 @@ -60,7 +60,7 @@ TiDB Cloud 为你提供了便捷的方式来查看告警、编辑告警规则， > - 你可以在 TiDB Cloud 控制台编辑告警的阈值。 > - 部分告警规则默认处于禁用状态。你可以根据需要启用它们。 -TiDB Cloud 会根据不同集群方案，结合该方案的功能，提供不同的告警规则。 +TiDB Cloud 会根据不同集群方案，结合该方案下可用的功能，提供不同的告警规则。 @@ -74,28 +74,28 @@ TiDB Cloud 会根据不同集群方案，结合该方案的功能，提供不同 | TiDB 节点 CPU 利用率超过 80% 持续 10 分钟 | 考虑增加 TiDB 节点数量或节点规格，以降低当前负载下的 CPU 使用百分比。| | TiKV 节点 CPU 利用率超过 80% 持续 10 分钟 | 考虑增加 TiKV 节点数量或节点规格，以降低当前负载下的 CPU 使用百分比。| | TiFlash 节点 CPU 利用率超过 80% 持续 10 分钟 | 考虑增加 TiFlash 节点数量或节点规格，以降低当前负载下的 CPU 使用百分比。| -| TiKV 存储利用率超过 80% | 考虑增加 TiKV 节点数量或节点存储容量，以提升你的存储能力。| -| TiFlash 存储利用率超过 80% | 考虑增加 TiFlash 节点数量或节点存储容量，以提升你的存储能力。| -| TiDB 节点最大内存利用率超过 70% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues) 问题，或增加 TiDB 节点数量或节点规格，以降低当前负载下的内存使用百分比。| -| TiKV 节点最大内存利用率超过 70% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues) 问题，或增加 TiKV 节点数量或节点规格，以降低当前负载下的内存使用百分比。| -| TiDB 节点最大 CPU 利用率超过 80% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues) 问题，或增加 TiDB 节点数量或节点规格，以降低当前负载下的 CPU 使用百分比。| -| TiKV 节点最大 CPU 利用率超过 80% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues) 问题，或增加 TiKV 节点数量或节点规格，以降低当前负载下的 CPU 使用百分比。| +| TiKV 存储利用率超过 80% | 考虑增加 TiKV 节点数量或节点存储容量，以提升存储能力。当 TiKV 存储使用率超过 80% 时，可能会出现延时激增，更高的使用率可能导致请求失败。| +| TiFlash 存储利用率超过 80% | 考虑增加 TiFlash 节点数量或节点存储容量，以提升存储能力。当所有 TiFlash 节点的存储使用率达到 80% 时，任何添加 TiFlash 副本的 DDL 语句都会无限期假死。| +| 集群中 TiDB 节点最大内存利用率超过 70% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues)，或增加 TiDB 节点数量或节点规格，以降低当前负载下的内存使用百分比。| +| 集群中 TiKV 节点最大内存利用率超过 70% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues)，或增加 TiKV 节点数量或节点规格，以降低当前负载下的内存使用百分比。| +| 集群中 TiDB 节点最大 CPU 利用率超过 80% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues)，或增加 TiDB 节点数量或节点规格，以降低当前负载下的 CPU 使用百分比。| +| 集群中 TiKV 节点最大 CPU 利用率超过 80% 持续 10 分钟 | 建议检查集群中是否存在 [热点](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues)，或增加 TiKV 节点数量或节点规格，以降低当前负载下的 CPU 使用百分比。| ### 数据迁移告警 | 条件 | 推荐操作 | |:--- |:--- | -| 数据迁移任务在数据导出过程中遇到错误 | 检查错误信息，并参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| -| 数据迁移任务在数据导入过程中遇到错误 | 检查错误信息，并参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| -| 数据迁移任务在增量迁移过程中遇到错误 | 检查错误信息，并参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| -| 数据迁移任务在增量迁移过程中已暂停超过 6 小时 | 数据迁移任务在数据增量迁移过程中已暂停超过 6 小时。上游数据库中的 binlog 可能已被清理（取决于你的数据库 binlog 清理策略），这可能导致增量迁移失败。请参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| -| 同步延迟大于 10 分钟且持续增长超过 20 分钟 | 请参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| +| 数据迁移任务在数据导出阶段遇到错误 | 检查错误信息，并参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| +| 数据迁移任务在数据导入阶段遇到错误 | 检查错误信息，并参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| +| 数据迁移任务在增量迁移阶段遇到错误 | 检查错误信息，并参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| +| 数据迁移任务在增量迁移阶段已暂停超过 6 小时 | 数据迁移任务在数据增量迁移阶段已暂停超过 6 小时。上游数据库中的 binlog 可能已被清理（取决于你的数据库 binlog 清理策略），这可能导致增量迁移失败。参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| +| 同步延迟超过 10 分钟且持续增长超过 20 分钟 | 参考 [数据迁移故障排查](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions) 获取帮助。| ### TiDB Cloud Dedicated 的 Changefeed 告警 -| 条件 | 推荐操作 | -|:----------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| changefeed 延时超过 600 秒 | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
可能触发该告警的原因包括：
  • 上游整体流量增加，导致现有 changefeed 规格无法承载。如果流量增加是暂时的，changefeed 延时会在流量恢复正常后自动恢复。如果流量持续增加，则需要扩展 changefeed。
  • 下游或网络异常，此时请先排查并解决异常。
  • 如果下游为 RDS，表缺少索引，可能导致写入性能低、延时高。此时需要在上游或下游添加必要的索引。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| +| 条件 | 推荐操作 | +|:----------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| changefeed 延时超过 600 秒 | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
可能触发该告警的原因包括：
  • 上游整体流量增加，导致现有 changefeed 规格无法承载。如果流量增加是暂时的，changefeed 延时会在流量恢复正常后自动恢复。如果流量持续增加，则需要扩展 changefeed。
  • 下游或网络异常，此时应先排查并解决异常。
  • 如果下游为 RDS，表缺少索引，可能导致写入性能低、延时高，此时需要为上游或下游添加必要的索引。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| | changefeed 状态为 `FAILED` | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| | changefeed 状态为 `WARNING` | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| @@ -107,17 +107,17 @@ TiDB Cloud 会根据不同集群方案，结合该方案的功能，提供不同 | 条件 | 推荐操作 | |:--- |:--- | -| 每秒请求单位（RU/s）超过最大 RCU 的 80% |
  1. 查看 RU 指标，判断增长是逐步的还是突发的。
  2. 如果是逐步增长，检查查询耗时是否增加。如果是，则当前最大 RCU 可能不足。
  3. 通过在 TiDB Cloud 控制台手动增加最大 RCU 来扩展容量。

如果你无法解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。| -| QPS 下降 80% |
  1. 检查下降是否由查询延时增加导致。
  2. 确认你的应用是否正常运行。如果下降是有意为之，可忽略该告警。如果下降非预期且无法定位根因，请立即联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。
| -| 查询 P99 延时超过 200 ms |
  1. 排查慢查询：进入 Slow Query 页面，按最近时间范围筛选，定位新出现或运行变慢的查询。
  2. 回顾近期变更，如应用部署、表结构变更或数据导入任务，这些可能影响流量模式。

如果无法定位根因，请立即联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。| -| 查询 P95 延时超过 200 ms |
  1. 排查慢查询：进入 Slow Query 页面，按最近时间范围筛选，定位新出现或运行变慢的查询。
  2. 回顾近期变更，如应用部署、表结构变更或数据导入任务，这些可能影响流量模式。

如果无法定位根因，请立即联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。| -| 请求错误率超过 10% | 检查集群的近期错误和整体语句执行情况。| +| 每秒请求单位（RU/s）超过最大 RCU 的 80% |
  1. 查看 RU 指标，判断增长是逐步的还是突发的。
  2. 如果是逐步增长，检查 query 时延是否增加。如果是，则当前最大 RCU 可能不足。
  3. 通过 TiDB Cloud 控制台手动增加最大 RCU 以扩展容量。

如果你无法解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。| +| QPS 下降 80% |
  1. 检查是否由于 query 延时增加导致下降。
  2. 确认你的应用是否正常运行。如果下降是有意为之，可忽略该告警。如果下降是非预期且无法定位根因，请立即联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。
| +| Query P99 延时超过 200 ms |
  1. 排查慢 query：进入 Slow Query 页面，按最近时间范围筛选，定位新引入或运行变慢的 query。
  2. 回顾近期变更，如应用部署、schema 变更或数据导入任务，这些可能影响流量模式。

如果无法定位根因，请立即联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。| +| Query P95 延时超过 200 ms |
  1. 排查慢 query：进入 Slow Query 页面，按最近时间范围筛选，定位新引入或运行变慢的 query。
  2. 回顾近期变更，如应用部署、schema 变更或数据导入任务，这些可能影响流量模式。

如果无法定位根因，请立即联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。| +| 请求错误率超过 10% | 检查集群近期错误和整体语句执行情况。| ### TiDB Cloud Essential 的 Changefeed 告警 | 条件 | 推荐操作 | -|:----------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| changefeed 延时超过 600 秒 | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
可能触发该告警的原因包括：
  • 上游整体流量增加，导致现有 changefeed 规格无法承载。如果流量增加是暂时的，changefeed 延时会在流量恢复正常后自动恢复。如果流量持续增加，则需要扩展 changefeed。
  • 下游或网络异常，此时请先排查并解决异常。
  • 如果下游为 RDS，表缺少索引，可能导致写入性能低、延时高。此时需要在上游或下游添加必要的索引。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| +|:----------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| changefeed 延时超过 600 秒 | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
可能触发该告警的原因包括：
  • 上游整体流量增加，导致现有 changefeed 规格无法承载。如果流量增加是暂时的，changefeed 延时会在流量恢复正常后自动恢复。如果流量持续增加，则需要扩展 changefeed。
  • 下游或网络异常，此时应先排查并解决异常。
  • 如果下游为 RDS，表缺少索引，可能导致写入性能低、延时高，此时需要为上游或下游添加必要的索引。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| | changefeed 状态为 `FAILED` | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| | changefeed 状态为 `WARNING` | 在 TiDB Cloud 控制台的 **Changefeed** 页面和 **Changefeed Detail** 页面检查 changefeed 状态，你可以在这些页面找到一些错误信息以帮助诊断问题。
如果你无法自行解决问题，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 获取进一步协助。| diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index ae1252d07b41c..ddfd9dd01accf 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -1,32 +1,32 @@ --- -title: 集成 TiDB Cloud 与 Datadog +title: 将 TiDB Cloud 集成到 Datadog summary: 了解如何通过 Datadog 集成监控你的 TiDB 集群。 --- -# 集成 TiDB Cloud 与 Datadog +# 将 TiDB Cloud 集成到 Datadog -TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你的 TiDB 集群的指标发送到 [Datadog](https://www.datadoghq.com/)。之后，你可以直接在 Datadog 仪表盘中查看这些指标。 +TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于 TiDB 集群的统计/指标（信息）发送到 [Datadog](https://www.datadoghq.com/)。之后，你可以直接在 Datadog 仪表盘中查看这些统计/指标（信息）。 ## Datadog 集成版本 -自 2022 年 3 月 4 日起，TiDB Cloud 支持项目级 Datadog 集成（Beta）。自 2025 年 7 月 31 日起，TiDB Cloud 推出了集群级 Datadog 集成（预览版）。自 2025 年 9 月 30 日起，集群级 Datadog 集成将正式发布（GA）。 +自 2022 年 3 月 4 日起，TiDB Cloud 支持项目级 Datadog 集成（Beta）。自 2025 年 7 月 31 日起，TiDB Cloud 推出集群级 Datadog 集成（预览版）。自 2025 年 9 月 30 日起，集群级 Datadog 集成将正式发布（GA）。 -- **集群级 Datadog 集成**：如果在 2025 年 7 月 31 日前，你的组织内没有未删除的遗留项目级 Datadog 或 New Relic 集成，TiDB Cloud 将为你的组织提供集群级 Datadog 集成，以体验最新的增强功能。 -- **遗留项目级 Datadog 集成（Beta）**：如果在 2025 年 7 月 31 日前，你的组织内至少有一个未删除的遗留项目级 Datadog 或 New Relic 集成，TiDB Cloud 会在项目级保留现有和新建的集成，以避免影响当前的仪表盘。请注意，遗留项目级 Datadog 集成将在 2025 年 10 月 31 日弃用。如果你的组织仍在使用这些遗留集成，请按照 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md) 迁移到新的集群级集成，以最大程度减少对指标相关服务的影响。 +- **集群级 Datadog 集成**：如果在 2025 年 7 月 31 日前，你的组织内没有未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 将为你的组织提供集群级 Datadog 集成，以体验最新增强功能。 +- **旧版项目级 Datadog 集成（Beta）**：如果在 2025 年 7 月 31 日前，你的组织内至少有一个未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 会在项目级保留现有和新建的集成，以避免影响当前仪表盘。请注意，旧版项目级 Datadog 集成将于 2025 年 10 月 31 日弃用。如果你的组织仍在使用这些旧版集成，请按照 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md) 迁移到新的集群级集成，以最大程度减少对统计/指标（信息）相关服务的影响。 ## 前提条件 -- 要将 TiDB Cloud 与 Datadog 集成，你必须拥有 Datadog 账号和 [Datadog API key](https://app.datadoghq.com/organization-settings/api-keys)。首次创建 Datadog 账号时，Datadog 会为你分配一个 API key。 +- 要将 TiDB Cloud 集成到 Datadog，你必须拥有 Datadog 账户和 [Datadog API key](https://app.datadoghq.com/organization-settings/api-keys)。首次创建 Datadog 账户时，Datadog 会为你分配一个 API key。 - 如果你还没有 Datadog 账号，请在 [https://app.datadoghq.com/signup](https://app.datadoghq.com/signup) 注册。 + 如果你还没有 Datadog 账户，请在 [https://app.datadoghq.com/signup](https://app.datadoghq.com/signup) 注册。 -- 要为 TiDB Cloud 设置第三方指标集成，你必须在 TiDB Cloud 中拥有 `Organization Owner` 或 `Project Owner` 权限。要通过提供的链接查看集成页面或访问已配置的仪表盘，你至少需要 `Project Viewer` 角色，以访问 TiDB Cloud 项目下的目标集群。 +- 要为 TiDB Cloud 设置第三方统计/指标（信息）集成，你必须在 TiDB Cloud 中拥有 `Organization Owner` 或 `Project Owner` 访问权限。要通过提供的链接查看集成页面或访问已配置的仪表盘，你至少需要 `Project Viewer` 角色，以访问项目下的目标集群。 ## 限制 - Datadog 集成目前仅适用于 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 -- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，无法使用 Datadog 集成。 +- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，不支持 Datadog 集成。 - 当带有 Datadog 集成的集群被删除时，其关联的集成服务也会被移除。 @@ -37,37 +37,37 @@ TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你 根据你的 [Datadog 集成版本](#datadog-integration-version)，访问集成页面的步骤有所不同。 -
+
1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入你项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称，进入其概览页面。 2. 在左侧导航栏，点击 **Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to Datadog**。 -4. 输入你的 Datadog API key 并选择你的 Datadog 站点。 +4. 输入你的 Datadog API key，并选择你的 Datadog site。 5. 点击 **Test Integration**。 - 如果测试成功，会显示 **Confirm** 按钮。 - - 如果测试失败，会显示错误信息。请根据提示进行排查并重试集成。 + - 如果测试失败，会显示错误信息。请根据提示排查并重试集成。 6. 点击 **Confirm** 完成集成。
-
+
1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，使用左上角的下拉框切换到你的目标项目。 2. 在左侧导航栏，点击 **Project Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to Datadog (BETA)**。 -4. 输入你的 Datadog API key 并选择你的 Datadog 站点。 +4. 输入你的 Datadog API key，并选择你的 Datadog site。 5. 点击 **Test Integration**。 - 如果测试成功，会显示 **Confirm** 按钮。 - - 如果测试失败，会显示错误信息。请根据提示进行排查并重试集成。 + - 如果测试失败，会显示错误信息。请根据提示排查并重试集成。 6. 点击 **Confirm** 完成集成。
-### 步骤 2. 在 Datadog 中安装 TiDB Cloud Integration +### 步骤 2. 在 Datadog 中安装 TiDB Cloud 集成 > **注意：** > @@ -78,56 +78,56 @@ TiDB Cloud 支持与 Datadog 集成。你可以配置 TiDB Cloud，将关于你 3. 在 **Configuration** 标签页，点击 **Install Integration**。 - 对于集群级 Datadog 集成，[**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker) 仪表盘会出现在你的 [**Dashboard List**](https://app.datadoghq.com/dashboard/lists) 中。 - - 对于遗留项目级 Datadog 集成（Beta），[**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview) 仪表盘会出现在你的 [**Dashboard List**](https://app.datadoghq.com/dashboard/lists) 中。 + - 对于旧版项目级 Datadog 集成（Beta），[**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview) 仪表盘会出现在你的 [**Dashboard List**](https://app.datadoghq.com/dashboard/lists) 中。 ## 查看预置仪表盘 1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，进入 **Integrations** 页面。 2. 在 **Datadog** 区域点击 **Dashboard** 链接。 - - 对于集群级 Datadog 集成，**Dashboard** 链接会打开新版仪表盘，包含增强版本中引入的最新指标。 - - 对于遗留项目级 Datadog 集成（Beta），**Dashboard** 链接会打开旧版仪表盘，不包含集群级 Datadog 集成中引入的最新指标。 + - 对于集群级 Datadog 集成，**Dashboard** 链接会打开新版仪表盘，包含增强版本中引入的最新统计/指标（信息）。 + - 对于旧版项目级 Datadog 集成（Beta），**Dashboard** 链接会打开旧版仪表盘，不包含集群级 Datadog 集成引入的最新统计/指标（信息）。 -## Datadog 可用指标 +## Datadog 可用统计/指标（信息） -Datadog 会跟踪你的 TiDB 集群的以下指标。 +Datadog 会跟踪你的 TiDB 集群的以下统计/指标（信息）。 -| 指标名称 | 指标类型 | 标签 | 描述 | +| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | | :------------| :---------- | :------| :----------------------------------------------------- | -| tidb_cloud.db_database_time| gauge | sql_type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | TiDB 中所有 SQL 语句每秒消耗的总时间，包括所有进程的 CPU 时间和非空闲等待时间。 | +| tidb_cloud.db_database_time| gauge | sql_type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒 TiDB 中所有 SQL 语句运行消耗的总时间，包括所有进程的 CPU 时间和非空闲等待时间。 | | tidb_cloud.db_query_per_second| gauge | type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 所有 TiDB 实例每秒执行的 SQL 语句数量，按语句类型（`SELECT`、`INSERT` 或 `UPDATE`）统计。 | -| tidb_cloud.db_average_query_duration| gauge | sql_type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 客户端网络请求发送到 TiDB 与 TiDB 执行后返回给客户端之间的持续时间。 | -| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每个 TiDB 实例每秒发生的 SQL 执行错误的错误类型统计（如语法错误、主键冲突等）。 | -| tidb_cloud.db_total_connection| gauge | cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 当前 TiDB 服务器中的连接数。 | +| tidb_cloud.db_average_query_duration| gauge | sql_type: Select\|Insert\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 客户端网络请求发送到 TiDB 与 TiDB 执行后返回给客户端之间的耗时。 | +| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒每个 TiDB 实例 SQL 执行错误的错误类型（如语法错误、主键冲突等）统计。 | +| tidb_cloud.db_total_connection| gauge | cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 当前 TiDB server 的连接数。 | | tidb_cloud.db_active_connections| gauge | cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 活跃连接数。 | | tidb_cloud.db_disconnections| gauge | result: ok\|error\|undetermined
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 断开连接的客户端数量。 | -| tidb_cloud.db_command_per_second| gauge | type: Query\|StmtPrepare\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | TiDB 每秒处理的命令数量，按命令执行结果的成功或失败分类。 | +| tidb_cloud.db_command_per_second| gauge | type: Query\|StmtPrepare\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | TiDB 每秒处理的命令数，按命令执行结果的成功或失败分类。 | | tidb_cloud.db_queries_using_plan_cache_ops| gauge | cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒使用 [Plan Cache](/sql-prepared-plan-cache.md) 的查询统计。执行计划缓存仅支持 prepared statement 命令。 | | tidb_cloud.db_transaction_per_second| gauge | txn_mode: pessimistic\|optimistic
type: abort\|commit\|...
cluster_name: ``
instance: tidb-0\|tidb-1…
component: `tidb` | 每秒执行的事务数量。 | -| tidb_cloud.node_storage_used_bytes | gauge | cluster_name: ``
instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…
component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘使用量（字节）。 | +| tidb_cloud.node_storage_used_bytes | gauge | cluster_name: ``
instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…
component: tikv\|tiflash | TiKV 或 TiFlash 节点的磁盘使用量（字节）。该统计/指标（信息）主要表示存储引擎中的逻辑数据大小，不包括 WAL 文件和临时文件。要计算实际磁盘使用率，请使用 `(capacity - available) / capacity`。当 TiKV 存储使用率超过 80% 时，可能会出现延时激增，更高的使用率可能导致请求失败。当所有 TiFlash 节点存储使用率达到 80% 时，任何添加 TiFlash 副本的 DDL 语句都会无限期假死。 | | tidb_cloud.node_storage_capacity_bytes | gauge | cluster_name: ``
instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…
component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘容量（字节）。 | | tidb_cloud.node_cpu_seconds_total | count | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的 CPU 使用量。 | | tidb_cloud.node_cpu_capacity_cores | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的 CPU 核心数上限。 | | tidb_cloud.node_memory_used_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点已用内存（字节）。 | | tidb_cloud.node_memory_capacity_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的内存容量（字节）。 | -对于集群级 Datadog 集成，还可获得以下额外指标： +对于集群级 Datadog 集成，还可获得以下附加统计/指标（信息）： -| 指标名称 | 指标类型 | 标签 | 描述 | +| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | | :------------| :---------- | :------| :----------------------------------------------------- | | tidb_cloud.node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: `` | TiKV/TiFlash 节点可用磁盘空间（字节）。 | -| tidb_cloud.node_disk_read_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延迟（秒）。 | -| tidb_cloud.node_disk_write_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延迟（秒）。 | -| tidb_cloud.db_kv_request_duration | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | 按类型统计的 TiKV 请求持续时间（秒）。 | +| tidb_cloud.node_disk_read_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延时（秒）。 | +| tidb_cloud.node_disk_write_latency | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延时（秒）。 | +| tidb_cloud.db_kv_request_duration | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 按类型请求的耗时（秒）。 | | tidb_cloud.db_component_uptime | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tidb\|tikv\|tiflash`
cluster_name: `` | TiDB 组件的运行时长（秒）。 | -| tidb_cloud.cdc_changefeed_latency (AKA cdc_changefeed_checkpoint_ts_lag) | gauge | changefeed_id: ``
cluster_name: ``| changefeed owner 的 checkpoint timestamp 延迟（秒）。 | -| tidb_cloud.cdc_changefeed_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved timestamp 延迟（秒）。 | +| tidb_cloud.cdc_changefeed_latency (AKA cdc_changefeed_checkpoint_ts_lag) | gauge | changefeed_id: ``
cluster_name: ``| changefeed owner 的 checkpoint 时间戳延迟（秒）。 | +| tidb_cloud.cdc_changefeed_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved 时间戳延迟（秒）。 | | tidb_cloud.cdc_changefeed_status | gauge | changefeed_id: ``
cluster_name: `` | Changefeed 状态：
`-1`: Unknown
`0`: Normal
`1`: Warning
`2`: Failed
`3`: Stopped
`4`: Finished
`6`: Warning
`7`: Other | | tidb_cloud.resource_manager_resource_unit_read_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的读请求单元（RU）。 | | tidb_cloud.resource_manager_resource_unit_write_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的写请求单元（RU）。 | | tidb_cloud.dm_task_state | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移任务状态：
0: Invalid
1: New
2: Running
3: Paused
4: Stopped
5: Finished
15: Error | -| tidb_cloud.dm_syncer_replication_lag_bucket | gauge | instance: `instance`
cluster_name: `` | 数据迁移的复制延迟（bucket）。 | -| tidb_cloud.dm_syncer_replication_lag_gauge | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移的复制延迟（gauge）。 | +| tidb_cloud.dm_syncer_replication_lag_bucket | gauge | instance: `instance`
cluster_name: `` | 数据迁移的同步延迟（bucket）。 | +| tidb_cloud.dm_syncer_replication_lag_gauge | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移的同步延迟（gauge）。 | | tidb_cloud.dm_relay_read_error_count | gauge | instance: `instance`
cluster_name: `` | 从主库读取 binlog 失败次数。 | | tidb_cloud.node_memory_available_bytes | gauge | cluster_name: ``
instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…
component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点可用内存（字节）。 | | tidb_cloud.cdc_changefeed_replica_rows | gauge | changefeed_id: ``
cluster_name: `` | TiCDC 节点每秒写入下游的事件数。 | \ No newline at end of file diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index f32fba64c94a5..279dfdf69e8f0 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -5,22 +5,22 @@ summary: 了解如何通过 New Relic 集成监控你的 TiDB 集群。 # 集成 TiDB Cloud 与 New Relic -TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB 集群的指标发送到 [New Relic](https://newrelic.com/)。之后，你可以直接在 New Relic 仪表盘中查看这些指标。 +TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将你的 TiDB 集群的统计/指标（信息）发送到 [New Relic](https://newrelic.com/)。之后，你可以直接在 New Relic 仪表盘中查看这些统计/指标（信息）。 ## New Relic 集成版本 自 2023 年 4 月 11 日起，TiDB Cloud 支持项目级 New Relic 集成（Beta）。自 2025 年 7 月 31 日起，TiDB Cloud 推出集群级 New Relic 集成（预览版）。自 2025 年 9 月 30 日起，集群级 New Relic 集成将正式发布（GA）。 -- **集群级 New Relic 集成**：如果在 2025 年 7 月 31 日前，你的组织内没有未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 将为你的组织提供集群级 New Relic 集成，以体验最新的增强功能。 -- **旧版项目级 New Relic 集成（Beta）**：如果在 2025 年 7 月 31 日前，你的组织内至少有一个未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 会在项目级保留现有和新建的集成，以避免影响当前的仪表盘。请注意，旧版项目级 New Relic 集成将于 2025 年 10 月 31 日弃用。如果你的组织仍在使用这些旧版集成，请按照 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md) 迁移到新的集群级集成，以最大程度减少对指标相关服务的影响。 +- **集群级 New Relic 集成**：如果在 2025 年 7 月 31 日前，你的组织内没有未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 将为你的组织提供集群级 New Relic 集成，以体验最新增强功能。 +- **旧版项目级 New Relic 集成（Beta）**：如果在 2025 年 7 月 31 日前，你的组织内至少有一个未删除的旧版项目级 Datadog 或 New Relic 集成，TiDB Cloud 会保留现有和新建的项目级集成，以避免影响当前仪表盘。请注意，旧版项目级 New Relic 集成将于 2025 年 10 月 31 日弃用。如果你的组织仍在使用这些旧版集成，请按照 [迁移 Datadog 和 New Relic 集成](/tidb-cloud/migrate-metrics-integrations.md) 迁移到新的集群级集成，以最大程度减少对统计/指标（信息）相关服务的影响。 ## 前提条件 -- 要将 TiDB Cloud 与 New Relic 集成，你必须拥有一个 [New Relic](https://newrelic.com/) 账号，并[创建一个 `Ingest - License` 类型的 New Relic API 密钥](https://one.newrelic.com/admin-portal/api-keys/home?)。 +- 要将 TiDB Cloud 集成到 New Relic，你必须拥有 [New Relic](https://newrelic.com/) 账户，并[创建一个 `Ingest - License` 类型的 New Relic API key](https://one.newrelic.com/admin-portal/api-keys/home?)。 - 如果你还没有 New Relic 账号，请在 [这里](https://newrelic.com/signup) 注册。 + 如果你还没有 New Relic 账户，请在 [这里](https://newrelic.com/signup) 注册。 -- 要为 TiDB Cloud 设置第三方指标集成，你必须在 TiDB Cloud 中拥有 **Organization Owner** 或 **Project Owner** 权限。要通过提供的链接查看集成页面或访问已配置的仪表盘，你至少需要 **Project Viewer** 角色，以访问项目下的目标集群。 +- 要为 TiDB Cloud 设置第三方统计/指标（信息）集成，你必须拥有 TiDB Cloud 的 `Organization Owner` 或 `Project Owner` 访问权限。要通过提供的链接查看集成页面或访问已配置的仪表盘，你至少需要 `Project Viewer` 角色，以访问 TiDB Cloud 项目下的目标集群。 ## 限制 @@ -28,11 +28,11 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB - 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，不支持 New Relic 集成。 -- 当删除已集成 New Relic 的集群时，其关联的集成服务也会被移除。 +- 当带有 New Relic 集成的集群被删除时，其关联的集成服务也会被移除。 ## 操作步骤 -### 步骤 1. 使用你的 New Relic API 密钥进行集成 +### 步骤 1. 使用你的 New Relic API Key 集成 根据你的 [New Relic 集成版本](#new-relic-集成版本)，访问集成页面的步骤有所不同。 @@ -42,7 +42,7 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB 1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入你项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称，进入其概览页面。 2. 在左侧导航栏，点击 **Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to New Relic**。 -4. 输入你的 New Relic API 密钥，并选择 New Relic 的站点。 +4. 输入你的 New Relic API key，并选择 New Relic 的站点。 5. 点击 **Test Integration**。 - 如果测试成功，会显示 **Confirm** 按钮。 @@ -53,10 +53,10 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB
-1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，使用左上角的下拉框切换到目标项目。 +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，使用左上角的下拉框切换到你的目标项目。 2. 在左侧导航栏，点击 **Project Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to New Relic (BETA)**。 -4. 输入你的 New Relic API 密钥，并选择 New Relic 的站点。 +4. 输入你的 New Relic API key，并选择 New Relic 的站点。 5. 点击 **Test Integration**。 - 如果测试成功，会显示 **Confirm** 按钮。 @@ -74,12 +74,12 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB
-在 New Relic 合并待处理的 [PR](https://github.com/newrelic/newrelic-quickstarts/pull/2681) 后，将会有新的 TiDB Cloud 仪表盘可用。在此之前，你可以通过以下步骤手动导入仪表盘： +在 New Relic 合并待处理的 [PR](https://github.com/newrelic/newrelic-quickstarts/pull/2681) 后，将会有新的 TiDB Cloud 仪表盘可用。在此之前，你可以通过以下步骤手动导入仪表盘到 New Relic： 1. 准备新仪表盘的 JSON 文件。 1. 在 [这里](https://github.com/pingcap/diag/blob/integration/integration/dashboards/newrelic-dashboard.json) 下载模板 JSON 文件。 - 2. 在 JSON 文件的第 4 行添加 `"permissions": "PUBLIC_READ_WRITE"`，如下所示： + 2. 在 JSON 文件第 4 行添加 `"permissions": "PUBLIC_READ_WRITE"`，如下所示： ```json { @@ -90,7 +90,7 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB } ``` - 3. 在 JSON 文件的所有 `"accountIds": []` 字段中，添加你的 New Relic 账号 ID。 + 3. 在 JSON 文件中所有 `"accountIds": []` 字段中，添加你的 New Relic 账户 ID。 例如： @@ -102,17 +102,17 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB > **注意**： > - > 为避免集成报错，请确保你的账号 ID 已添加到 JSON 文件中所有 `"accountIds"` 字段。 + > 为避免集成报错，请确保你的账户 ID 已添加到 JSON 文件中所有 `"accountIds"` 字段。 2. 登录 [New Relic](https://one.newrelic.com/)，点击左侧导航栏的 **Dashboards**，然后点击右上角的 **Import dashboard**。 -3. 在弹出的对话框中，将准备好的 JSON 文件内容全部粘贴到文本区域，然后点击 **Import dashboard**。 +3. 在弹出的对话框中，将准备好的 JSON 文件内容全部粘贴到文本框中，然后点击 **Import dashboard**。
1. 登录 [New Relic](https://one.newrelic.com/)。 -2. 点击 **Add Data**，搜索 `TiDB Cloud`，然后进入 **TiDB Cloud Monitoring** 页面。你也可以直接点击 [链接](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e) 访问该页面。 -3. 选择你的账号 ID，并在 New Relic 中创建仪表盘。 +2. 点击 **Add Data**，搜索 `TiDB Cloud`，然后进入 **TiDB Cloud Monitoring** 页面。你也可以点击 [此链接](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e) 直接访问该页面。 +3. 选择你的账户 ID，并在 New Relic 中创建仪表盘。
@@ -121,47 +121,47 @@ TiDB Cloud 支持与 New Relic 集成。你可以配置 TiDB Cloud，将 TiDB 1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入 **Integrations** 页面。 -2. 在 **New Relic** 区域点击 **Dashboard** 链接，查看 TiDB 集群的预置仪表盘。 +2. 在 **New Relic** 区域点击 **Dashboard** 链接，查看你的 TiDB 集群的预置仪表盘。 3. 根据你的 [New Relic 集成版本](#new-relic-集成版本)，执行以下操作之一： - 对于集群级 New Relic 集成，点击 **TiDB Cloud Dynamic Tracker** 查看新仪表盘。 - 对于旧版项目级 New Relic 集成（Beta），点击 **TiDB Cloud Monitoring** 查看旧版仪表盘。 -## New Relic 可用指标 +## New Relic 可用统计/指标（信息） -New Relic 会跟踪你的 TiDB 集群的以下指标。 +New Relic 会跟踪你的 TiDB 集群的以下统计/指标（信息）。 -| 指标名称 | 指标类型 | 标签 | 描述 | +| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | | :------------| :---------- | :------| :----------------------------------------------------- | -| tidb_cloud.db_database_time| gauge | sql_type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒 TiDB 中所有 SQL 语句运行消耗的总时间，包括所有进程的 CPU 时间和非空闲等待时间。 | -| tidb_cloud.db_query_per_second| gauge | type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 所有 TiDB 实例每秒执行的 SQL 语句数量，按 `SELECT`、`INSERT`、`UPDATE` 等类型统计。 | -| tidb_cloud.db_average_query_duration| gauge | sql_type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 客户端网络请求发送到 TiDB 与 TiDB 执行后返回给客户端之间的耗时。 | -| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒每个 TiDB 实例 SQL 执行错误的类型统计（如语法错误、主键冲突等）。 | -| tidb_cloud.db_total_connection| gauge | cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 当前 TiDB 服务器的连接数。 | +| tidb_cloud.db_database_time| gauge | sql_type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒在 TiDB 中运行的所有 SQL 语句消耗的总时间，包括所有进程的 CPU 时间和非空闲等待时间。 | +| tidb_cloud.db_query_per_second| gauge | type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 所有 TiDB 实例每秒执行的 SQL 语句数量，按 `SELECT`、`INSERT`、`UPDATE` 等语句类型统计。 | +| tidb_cloud.db_average_query_duration| gauge | sql_type: Select\|Insert\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 客户端网络请求发送到 TiDB 到 TiDB 执行后返回给客户端的时间间隔。 | +| tidb_cloud.db_failed_queries| gauge | type: executor:xxxx\|parser:xxxx\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒每个 TiDB 实例发生的 SQL 执行错误的错误类型统计（如语法错误、主键冲突等）。 | +| tidb_cloud.db_total_connection| gauge | cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 当前 TiDB server 的连接数。 | | tidb_cloud.db_active_connections| gauge | cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 活跃连接数。 | | tidb_cloud.db_disconnections| gauge | result: ok\|error\|undetermined

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 断开连接的客户端数量。 | | tidb_cloud.db_command_per_second| gauge | type: Query\|StmtPrepare\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | TiDB 每秒处理的命令数，按命令执行结果的成功或失败分类。 | | tidb_cloud.db_queries_using_plan_cache_ops| gauge | cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒使用 [Plan Cache](/sql-prepared-plan-cache.md) 的查询统计。执行计划缓存仅支持 prepared statement 命令。 | -| tidb_cloud.db_transaction_per_second| gauge | txn_mode: pessimistic\|optimistic

type: abort\|commit\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒执行的事务数。 | -| tidb_cloud.node_storage_used_bytes | gauge | cluster_name: ``

instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…

component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘使用量（字节）。 | +| tidb_cloud.db_transaction_per_second| gauge | txn_mode: pessimistic\|optimistic

type: abort\|commit\|...

cluster_name: ``

instance: tidb-0\|tidb-1…

component: `tidb` | 每秒执行的事务数量。 | +| tidb_cloud.node_storage_used_bytes | gauge | cluster_name: ``

instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…

component: tikv\|tiflash | TiKV 或 TiFlash 节点的磁盘使用量（字节）。该统计/指标（信息）主要表示存储引擎中的逻辑数据大小，不包括 WAL 文件和临时文件。要计算实际磁盘使用率，请使用 `(capacity - available) / capacity`。当 TiKV 存储使用率超过 80% 时，可能会出现延时激增，更高的使用率可能导致请求失败。当所有 TiFlash 节点存储使用率达到 80% 时，任何添加 TiFlash 副本的 DDL 语句都会无限期假死。 | | tidb_cloud.node_storage_capacity_bytes | gauge | cluster_name: ``

instance: tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…

component: tikv\|tiflash | TiKV/TiFlash 节点的磁盘容量（字节）。 | | tidb_cloud.node_cpu_seconds_total (Beta only) | count | cluster_name: ``

instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…

component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的 CPU 使用量。 | | tidb_cloud.node_cpu_capacity_cores | gauge | cluster_name: ``

instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…

component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的 CPU 核心数上限。 | | tidb_cloud.node_memory_used_bytes | gauge | cluster_name: ``

instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…

component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点已用内存（字节）。 | | tidb_cloud.node_memory_capacity_bytes | gauge | cluster_name: ``

instance: tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…

component: tidb\|tikv\|tiflash | TiDB/TiKV/TiFlash 节点的内存容量（字节）。 | -对于集群级 New Relic 集成，还支持以下附加指标： +对于集群级 New Relic 集成，还支持以下额外统计/指标（信息）： -| 指标名称 | 指标类型 | 标签 | 描述 | +| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | | :------------| :---------- | :------| :----------------------------------------------------- | | tidb_cloud.node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: `` | TiKV 或 TiFlash 节点可用磁盘空间（字节）。 | -| tidb_cloud.node_disk_read_latency | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: ``

`device`: `nvme.*\|dm.*` | 每个存储设备的读延迟（秒）。 | -| tidb_cloud.node_disk_write_latency | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: ``

`device`: `nvme.*\|dm.*` | 每个存储设备的写延迟（秒）。 | +| tidb_cloud.node_disk_read_latency | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: ``

`device`: `nvme.*\|dm.*` | 每个存储设备的读延时（秒）。 | +| tidb_cloud.node_disk_write_latency | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv\|tiflash`

cluster_name: ``

`device`: `nvme.*\|dm.*` | 每个存储设备的写延时（秒）。 | | tidb_cloud.db_kv_request_duration | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tikv`

cluster_name: ``

`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 按类型请求的耗时（秒）。 | | tidb_cloud.db_component_uptime | gauge | instance: `tidb-0\|tidb-1\|...`

component: `tidb\|tikv\|tiflash`

cluster_name: `` | TiDB 组件的运行时长（秒）。 | -| tidb_cloud.cdc_changefeed_latency (AKA cdc_changefeed_checkpoint_ts_lag) | gauge | changefeed_id: ``

cluster_name: ``| changefeed owner 的 checkpoint timestamp 延迟（秒）。 | -| tidb_cloud.cdc_changefeed_resolved_ts_lag | gauge | changefeed_id: ``

cluster_name: `` | changefeed owner 的 resolved timestamp 延迟（秒）。 | +| tidb_cloud.cdc_changefeed_latency (AKA cdc_changefeed_checkpoint_ts_lag) | gauge | changefeed_id: ``

cluster_name: ``| changefeed owner 的 checkpoint 时间戳延迟（秒）。 | +| tidb_cloud.cdc_changefeed_resolved_ts_lag | gauge | changefeed_id: ``

cluster_name: `` | changefeed owner 的 resolved 时间戳延迟（秒）。 | | tidb_cloud.cdc_changefeed_status | gauge | changefeed_id: ``

cluster_name: `` | Changefeed 状态：

`-1`: Unknown

`0`: Normal

`1`: Warning

`2`: Failed

`3`: Stopped

`4`: Finished

`6`: Warning

`7`: Other | | tidb_cloud.resource_manager_resource_unit_read_request_unit | gauge | cluster_name: ``

resource_group: `` | Resource Manager 消耗的读请求单元（RU）。 | | tidb_cloud.resource_manager_resource_unit_write_request_unit | gauge | cluster_name: ``

resource_group: `` | Resource Manager 消耗的写请求单元（RU）。 | diff --git a/tidb-cloud/monitor-prometheus-and-grafana-integration.md b/tidb-cloud/monitor-prometheus-and-grafana-integration.md index 6d6564f362c60..8229ec7deca8d 100644 --- a/tidb-cloud/monitor-prometheus-and-grafana-integration.md +++ b/tidb-cloud/monitor-prometheus-and-grafana-integration.md @@ -1,13 +1,13 @@ --- title: 集成 TiDB Cloud 与 Prometheus 和 Grafana -summary: 了解如何通过集成 Prometheus 和 Grafana 监控你的 TiDB 集群。 +summary: 了解如何通过 Prometheus 和 Grafana 集成监控你的 TiDB 集群。 --- # 集成 TiDB Cloud 与 Prometheus 和 Grafana -TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点。如果你拥有 Prometheus service，可以轻松地通过该端点监控 TiDB Cloud 的关键统计/指标（信息）。 +TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点。如果你拥有 Prometheus 服务，可以轻松地通过该端点监控 TiDB Cloud 的关键统计/指标（信息）。 -本文档介绍了如何配置你的 Prometheus service 以从 TiDB Cloud 端点读取关键统计/指标（信息），以及如何使用 [Grafana](https://grafana.com/) 查看这些统计/指标（信息）。 +本文档介绍了如何配置你的 Prometheus 服务以从 TiDB Cloud 端点读取关键统计/指标（信息），以及如何使用 [Grafana](https://grafana.com/) 查看这些统计/指标（信息）。 ## Prometheus 集成版本 @@ -15,35 +15,35 @@ TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点。如 - **集群级 Prometheus 集成**：如果在 2025 年 10 月 21 日前，你的组织内没有未删除的遗留项目级 Prometheus 集成，TiDB Cloud 将为你的组织提供集群级 Prometheus 集成，以体验最新增强功能。 -- **遗留项目级 Prometheus 集成（Beta）**：如果在 2025 年 10 月 21 日前，你的组织内至少有一个未删除的遗留项目级 Prometheus 集成，TiDB Cloud 会为你的组织保留现有和新建的项目级集成，以避免影响当前的仪表盘。 +- **遗留项目级 Prometheus 集成（Beta）**：如果在 2025 年 10 月 21 日前，你的组织内至少有一个未删除的遗留项目级 Prometheus 集成，TiDB Cloud 会在项目级别保留现有和新建的集成，以避免影响当前的仪表盘。 > **注意** > - > 遗留项目级 Prometheus 集成将于 2026 年 1 月 9 日弃用。如果你的组织仍在使用这些遗留集成，请按照 [迁移 Prometheus 集成](/tidb-cloud/migrate-prometheus-metrics-integrations.md) 迁移到新的集群级集成，以最大程度减少对统计/指标（信息）相关 service 的影响。 + > 遗留项目级 Prometheus 集成将于 2026 年 1 月 9 日弃用。如果你的组织仍在使用这些遗留集成，请按照 [迁移 Prometheus 集成](/tidb-cloud/migrate-prometheus-metrics-integrations.md) 指南迁移到新的集群级集成，以最大程度减少对统计/指标（信息）相关服务的影响。 ## 前提条件 -- 若要集成 TiDB Cloud 与 Prometheus，你必须拥有自托管或托管的 Prometheus service。 +- 若要集成 TiDB Cloud 与 Prometheus，你必须拥有自托管或托管的 Prometheus 服务。 - 若要为 TiDB Cloud 设置第三方统计/指标（信息）集成，你必须在 TiDB Cloud 中拥有 `Organization Owner` 或 `Project Owner` 访问权限。若要查看集成页面，你至少需要 `Project Viewer` 角色，以访问 TiDB Cloud 项目下的目标集群。 ## 限制 - Prometheus 和 Grafana 集成目前仅适用于 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群。 -- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，不支持 Prometheus 和 Grafana 集成。 +- 当集群状态为 **CREATING**、**RESTORING**、**PAUSED** 或 **RESUMING** 时，Prometheus 和 Grafana 集成不可用。 ## 步骤 ### 步骤 1. 获取 Prometheus 的 scrape_config 文件 -在配置 Prometheus service 以读取 TiDB Cloud 统计/指标（信息）之前，你需要先在 TiDB Cloud 中生成一个 `scrape_config` YAML 文件。该 `scrape_config` 文件包含一个唯一的 bearer token，允许 Prometheus service 监控你的目标集群。 +在配置 Prometheus 服务以读取 TiDB Cloud 统计/指标（信息）之前，你需要先在 TiDB Cloud 中生成一个 `scrape_config` YAML 文件。该 `scrape_config` 文件包含一个唯一的 bearer token，允许 Prometheus 服务监控你的目标集群。 根据你的 [Prometheus 集成版本](#prometheus-integration-versions)，获取 Prometheus 的 `scrape_config` 文件及访问集成页面的步骤有所不同。
-1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，进入你项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称进入其概览页面。 +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com/)中，导航到你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面，然后点击目标集群名称进入其概览页面。 2. 在左侧导航栏，点击 **Settings** > **Integrations**。 3. 在 **Integrations** 页面，点击 **Integration to Prometheus**。 4. 点击 **Add File**，为当前集群生成并显示 `scrape_config` 文件。 @@ -63,21 +63,21 @@ TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点。如 > **注意：** > -> 出于安全考虑，TiDB Cloud 仅会显示新生成的 `scrape_config` 文件一次。请确保在关闭文件窗口前复制内容。如果忘记复制，需要在 TiDB Cloud 中删除该 `scrape_config` 文件并重新生成。要删除 `scrape_config` 文件，选择该文件，点击 **...**，然后点击 **Delete**。 +> 出于安全考虑，TiDB Cloud 只会显示新生成的 `scrape_config` 文件一次。请确保在关闭文件窗口前复制内容。如果忘记复制，需要在 TiDB Cloud 中删除该 `scrape_config` 文件并重新生成。要删除 `scrape_config` 文件，选择该文件，点击 **...**，然后点击 **Delete**。 ### 步骤 2. 集成 Prometheus -1. 在你的 Prometheus service 指定的监控目录中，找到 Prometheus 配置文件。 +1. 在你的 Prometheus 服务指定的监控目录中，找到 Prometheus 配置文件。 - 例如，`/etc/prometheus/prometheus.yml`。 + 例如：`/etc/prometheus/prometheus.yml`。 2. 在 Prometheus 配置文件中，找到 `scrape_configs` 部分，然后将从 TiDB Cloud 获取的 `scrape_config` 文件内容复制到该部分。 -3. 在你的 Prometheus service 中，检查 **Status** > **Targets**，确认新的 `scrape_config` 文件已被读取。如果没有，你可能需要重启 Prometheus service。 +3. 在你的 Prometheus 服务中，检查 **Status** > **Targets**，确认新的 `scrape_config` 文件已被读取。如果没有生效，可能需要重启 Prometheus 服务。 ### 步骤 3. 使用 Grafana GUI 仪表盘可视化统计/指标（信息） -当你的 Prometheus service 已经从 TiDB Cloud 读取统计/指标（信息）后，可以按如下方式使用 Grafana GUI 仪表盘进行可视化： +当你的 Prometheus 服务已从 TiDB Cloud 读取统计/指标（信息）后，可以通过 Grafana GUI 仪表盘进行可视化，操作如下： 1. 根据你的 [Prometheus 集成版本](#prometheus-integration-versions)，下载 TiDB Cloud for Prometheus 的 Grafana 仪表盘 JSON 文件的链接不同。 @@ -88,9 +88,9 @@ TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点。如 > **注意：** > - > 如果你已经在使用 Prometheus 和 Grafana 监控 TiDB Cloud，并希望引入新可用的统计/指标（信息），建议新建一个仪表盘，而不是直接更新现有仪表盘的 JSON。 + > 如果你已经在使用 Prometheus 和 Grafana 监控 TiDB Cloud，并希望引入新上线的统计/指标（信息），建议新建一个仪表盘，而不是直接更新现有仪表盘的 JSON。 -3. （可选）根据需要自定义仪表盘，例如添加或移除面板、变更数据源、修改显示选项等。 +3. （可选）根据需要自定义仪表盘，例如添加或移除面板、修改数据源、调整显示选项等。 关于如何使用 Grafana 的更多信息，请参见 [Grafana 官方文档](https://grafana.com/docs/grafana/latest/getting-started/getting-started-prometheus/)。 @@ -98,47 +98,47 @@ TiDB Cloud 提供了一个 [Prometheus](https://prometheus.io/) API 端点。如 为提升数据安全性，建议定期轮转 `scrape_config` 文件的 bearer token。 -1. 按照 [步骤 1](#step-1-get-a-scrape_config-file-for-prometheus) 为 Prometheus 创建新的 `scrape_config` 文件。 +1. 按照 [步骤 1](#step-1-get-a-scrape_config-file-for-prometheus) 创建新的 Prometheus `scrape_config` 文件。 2. 将新文件内容添加到你的 Prometheus 配置文件中。 -3. 确认 Prometheus service 仍能从 TiDB Cloud 读取后，从 Prometheus 配置文件中移除旧的 `scrape_config` 文件内容。 -4. 在项目或集群的 **Integrations** 页面，删除对应的旧 `scrape_config` 文件，阻止他人使用其读取 TiDB Cloud Prometheus 端点。 +3. 确认 Prometheus 服务仍能从 TiDB Cloud 读取后，从 Prometheus 配置文件中移除旧的 `scrape_config` 文件内容。 +4. 在项目或集群的 **Integrations** 页面，删除对应的旧 `scrape_config` 文件，防止他人利用其读取 TiDB Cloud Prometheus 端点。 ## Prometheus 可用统计/指标（信息） Prometheus 会跟踪你的 TiDB 集群的以下统计/指标（信息）数据。 -| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | +| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | |:--- |:--- |:--- |:--- | -| tidbcloud_db_queries_total| count | sql_type: `Select\|Insert\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 执行的 statement 总数 | -| tidbcloud_db_failed_queries_total | count | type: `planner:xxx\|executor:2345\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 执行错误总数 | +| tidbcloud_db_queries_total| count | sql_type: `Select\|Insert\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 执行的语句总数 | +| tidbcloud_db_failed_queries_total | count | type: `planner:xxx\|executor:2345\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 执行错误的总数 | | tidbcloud_db_connections | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 当前 TiDB server 的连接数 | -| tidbcloud_db_query_duration_seconds | histogram | sql_type: `Select\|Insert\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | statement 的耗时直方图 | -| tidbcloud_changefeed_latency | gauge | changefeed_id | changefeed 上游与下游间的数据同步延时 | -| tidbcloud_changefeed_checkpoint_ts | gauge | changefeed_id | changefeed 的 checkpoint 时间戳，表示已成功写入下游的最大 TSO（Timestamp Oracle）| -| tidbcloud_changefeed_replica_rows | gauge | changefeed_id | changefeed 每秒写入下游的副本行数 | -| tidbcloud_node_storage_used_bytes | gauge | cluster_name: ``
instance: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
component: `tikv\|tiflash` | TiKV/TiFlash 节点的磁盘已用字节数 | -| tidbcloud_node_storage_capacity_bytes | gauge | cluster_name: ``
instance: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
component: `tikv\|tiflash` | TiKV/TiFlash 节点的磁盘容量字节数 | +| tidbcloud_db_query_duration_seconds | histogram | sql_type: `Select\|Insert\|...`
cluster_name: ``
instance: `tidb-0\|tidb-1…`
component: `tidb` | 语句的耗时直方图 | +| tidbcloud_changefeed_latency | gauge | changefeed_id | changefeed 上游与下游的数据同步延时 | +| tidbcloud_changefeed_checkpoint_ts | gauge | changefeed_id | changefeed 的 checkpoint 时间戳，代表已成功写入下游的最大 TSO（Timestamp Oracle） | +| tidbcloud_changefeed_replica_rows | gauge | changefeed_id | changefeed 每秒写入下游的同步行数 | +| tidbcloud_node_storage_used_bytes | gauge | cluster_name: ``
instance: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
component: `tikv\|tiflash` | TiKV 或 TiFlash 节点的磁盘使用量（字节）。该统计/指标（信息）主要表示存储引擎中的逻辑数据大小，不包含 WAL 文件和临时文件。实际磁盘使用率建议用 `(capacity - available) / capacity` 计算。当 TiKV 存储使用率超过 80% 时，可能出现延时激增，使用率更高时可能导致请求失败。当所有 TiFlash 节点存储使用率达到 80% 时，任何添加 TiFlash 副本的 DDL 语句都会无限期假死。 | +| tidbcloud_node_storage_capacity_bytes | gauge | cluster_name: ``
instance: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
component: `tikv\|tiflash` | TiKV/TiFlash 节点的磁盘容量（字节） | | tidbcloud_node_cpu_seconds_total | count | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的 CPU 使用量 | | tidbcloud_node_cpu_capacity_cores | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的 CPU 限制核数 | -| tidbcloud_node_memory_used_bytes | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的已用内存字节数 | -| tidbcloud_node_memory_capacity_bytes | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的内存容量字节数 | -| tidbcloud_node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: `` | TiKV/TiFlash 节点可用磁盘空间（字节）| -| tidbcloud_disk_read_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延时（秒）| -| tidbcloud_disk_write_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延时（秒）| -| tidbcloud_kv_request_duration | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 各类型请求的耗时（秒）| -| tidbcloud_component_uptime | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tidb\|tikv\|tiflash`
cluster_name: `` | TiDB 组件的运行时长（秒）| -| tidbcloud_ticdc_owner_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved 时间戳延时（秒）| -| tidbcloud_changefeed_status | gauge | changefeed_id: ``
cluster_name: `` | changefeed 状态：
`-1`: 未知
`0`: 正常
`1`: 警告
`2`: 失败
`3`: 已停止
`4`: 已完成
`6`: 警告
`7`: 其他 | -| tidbcloud_resource_manager_resource_unit_read_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的读请求单元数 | -| tidbcloud_resource_manager_resource_unit_write_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的写请求单元数 | +| tidbcloud_node_memory_used_bytes | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的已用内存（字节） | +| tidbcloud_node_memory_capacity_bytes | gauge | cluster_name: ``
instance: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
component: `tidb\|tikv\|tiflash` | TiDB/TiKV/TiFlash 节点的内存容量（字节） | +| tidbcloud_node_storage_available_bytes | gauge | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: `` | TiKV/TiFlash 节点的可用磁盘空间（字节） | +| tidbcloud_disk_read_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的读延时（秒） | +| tidbcloud_disk_write_latency | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv\|tiflash`
cluster_name: ``
`device`: `nvme.*\|dm.*` | 每个存储设备的写延时（秒） | +| tidbcloud_kv_request_duration | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tikv`
cluster_name: ``
`type`: `BatchGet\|Commit\|Prewrite\|...` | TiKV 各类型请求的耗时（秒） | +| tidbcloud_component_uptime | histogram | instance: `tidb-0\|tidb-1\|...`
component: `tidb\|tikv\|tiflash`
cluster_name: `` | TiDB 组件的运行时长（秒） | +| tidbcloud_ticdc_owner_resolved_ts_lag | gauge | changefeed_id: ``
cluster_name: `` | changefeed owner 的 resolved 时间戳延迟（秒） | +| tidbcloud_changefeed_status | gauge | changefeed_id: ``
cluster_name: `` | changefeed 状态：
`-1`: Unknown
`0`: Normal
`1`: Warning
`2`: Failed
`3`: Stopped
`4`: Finished
`6`: Warning
`7`: Other | +| tidbcloud_resource_manager_resource_unit_read_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的读请求单元 | +| tidbcloud_resource_manager_resource_unit_write_request_unit | gauge | cluster_name: ``
resource_group: `` | Resource Manager 消耗的写请求单元 | 对于集群级 Prometheus 集成，还可获取以下额外统计/指标（信息）： -| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | +| 统计/指标（信息）名称 | 统计/指标（信息）类型 | 标签 | 描述 | |:--- |:--- |:--- |:--- | | tidbcloud_dm_task_status | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移任务状态：
0: Invalid
1: New
2: Running
3: Paused
4: Stopped
5: Finished
15: Error | -| tidbcloud_dm_syncer_replication_lag_bucket | gauge | instance: `instance`
cluster_name: `` | 数据迁移的同步延时（bucket）| -| tidbcloud_dm_syncer_replication_lag_gauge | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移的同步延时（gauge）| +| tidbcloud_dm_syncer_replication_lag_bucket | gauge | instance: `instance`
cluster_name: `` | 数据迁移的同步延迟（bucket） | +| tidbcloud_dm_syncer_replication_lag_gauge | gauge | instance: `instance`
task: `task`
cluster_name: `` | 数据迁移的同步延迟（gauge） | | tidbcloud_dm_relay_read_error_count | count | instance: `instance`
cluster_name: `` | 从主库读取 binlog 失败的次数 | ## 常见问题 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index d49a374fdf6d6..0756bc3f5f174 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -8,31 +8,61 @@ aliases: ['/zh/tidbcloud/supported-tidb-versions','/zh/tidbcloud/release-notes'] 本页面列出了 [TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 在 2026 年的发布说明。 +## 2026 年 3 月 10 日 + +**通用变更** + +- **TiDB Cloud Essential** + + - 在数据流场景下，私有链路连接支持 Amazon MSK Provisioned。 + + [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 现已支持通过私有链路连接到 [Amazon MSK Provisioned](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provisioned.html) 集群。该功能使变更数据流（changefeed）能够通过私有网络连接到 Amazon MSK Provisioned 集群，无需将流量暴露到公网。 + + 详情参见 [通过私有链路连接 Amazon MSK Provisioned](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)。 + +## 2026 年 3 月 3 日 + +**通用变更** + +- **TiDB Cloud Dedicated** + + - 支持为 Amazon S3 sink 的 changefeed 使用 AWS Role ARN 进行认证。 + + 现在，你可以在 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群上为 Amazon S3 sink 的 changefeed 配置 IAM Role ARN，除了现有的 AK/SK 认证方式外。该功能通过启用短时凭证和自动轮换提升安全性，简化密钥管理，并支持最小权限实践。 + + 详情参见 [同步到云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 + + - 优化 TiKV 和 TiFlash 的存储用量计算。 + + 现在，TiKV 和 TiFlash 的存储用量计算在统计/指标（信息）和告警系统中会包含 WAL 文件和临时文件，从而提供更准确的容量和用量监控。 + + 详情参见 [TiDB Cloud 内置统计/指标（信息）](/tidb-cloud/built-in-monitoring.md)。 + ## 2026 年 2 月 10 日 **通用变更** - **TiDB Cloud Starter** - - 将新建 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本从 [v7.5.6](https://docs.pingcap.com/tidb/stable/release-7.5.6) 升级到 [v8.5.3](https://docs.pingcap.com/tidb/stable/release-8.5.3)。 + - 新建 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群的默认 TiDB 版本由 [v7.5.6](https://docs.pingcap.com/tidb/stable/release-7.5.6) 升级至 [v8.5.3](https://docs.pingcap.com/tidb/stable/release-8.5.3)。 - **TiDB Cloud Essential** - - 支持内置报警/告警。 + - 支持内置告警。 - 内置报警/告警功能允许你通过 email、Slack、Zoom、Flashduty 和 PagerDuty 订阅并接收即时报警/告警。你还可以通过为每种报警/告警类型定义特定阈值，来自定义报警/告警。 + 内置告警允许你通过邮件、Slack、Zoom、Flashduty 和 PagerDuty 订阅并接收即时告警。你还可以为每种告警类型自定义阈值。 - 更多信息，参见 [TiDB Cloud Built-in Alerting](https://docs.pingcap.com/tidbcloud/monitor-built-in-alerting/?plan=essential)。 + 详情参见 [TiDB Cloud 内置告警](https://docs.pingcap.com/tidbcloud/monitor-built-in-alerting/?plan=essential)。 - **TiDB Cloud Dedicated** - 支持通过 Private Link 从 Azure Blob Storage 导入数据。 + + 当你将数据从 Azure Blob Storage 导入到 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群时，现在可以选择 Private Link 作为连接方式，通过 Azure 私有端点进行连接，而无需经过公网。该功能为限制公网访问的存储账户提供了安全、网络隔离的数据导入能力。 - 当你将数据从 Azure Blob Storage 导入到 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群时，现在可以选择 Private Link 作为连接方式，通过 Azure 私有端点进行连接，而不是通过公网。该功能为限制公网访问的存储账户提供了安全、网络隔离的数据导入能力。 - - 更多信息，参见 [从云存储导入示例数据（SQL 文件）](/tidb-cloud/import-sample-data.md)、[从云存储导入 CSV 文件](/tidb-cloud/import-csv-files.md) 和 [从云存储导入 Apache Parquet 文件](/tidb-cloud/import-parquet-files.md)。 + 详情参见 [从云存储导入示例数据（SQL 文件）](/tidb-cloud/import-sample-data.md)、[从云存储导入 CSV 文件](/tidb-cloud/import-csv-files.md) 和 [从云存储导入 Apache Parquet 文件](/tidb-cloud/import-parquet-files.md)。 - - 在 TiDB Cloud 的 Console 审计日志中新增 “启用/禁用公网端点” 事件，以便更好地进行安全追踪。 + - 在 TiDB Cloud 控制台审计日志中新增“启用/禁用公网端点”事件，以提升安全追踪能力。 ## 2026 年 2 月 3 日 @@ -40,11 +70,11 @@ aliases: ['/zh/tidbcloud/supported-tidb-versions','/zh/tidbcloud/release-notes'] - **TiDB Cloud Dedicated** - - 支持将变更数据下沉到 Azure Blob Storage。 + - 支持将 changefeed 数据同步到 Azure Blob Storage。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 现在支持将变更数据（changefeed）直接下沉到 Azure Blob Storage。该功能使基于 Azure 的用户能够高效归档变更数据，用于下游分析和长期保存。同时，通过省去中间消息队列，降低了成本，并保持了与现有 Amazon S3 和 Google Cloud Storage (GCS) 下沉格式的兼容性。 + [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 现已支持将 changefeed 数据直接同步到 Azure Blob Storage。该功能使基于 Azure 的用户能够高效归档变更数据，便于下游分析和长期保存。同时，通过省去中间消息队列降低成本，并保持与现有 Amazon S3 和 Google Cloud Storage (GCS) sink 的格式兼容。 - 更多信息，参见 [下沉到云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 + 详情参见 [同步到云存储](/tidb-cloud/changefeed-sink-to-cloud-storage.md)。 ## 2026 年 1 月 27 日 @@ -52,11 +82,11 @@ aliases: ['/zh/tidbcloud/supported-tidb-versions','/zh/tidbcloud/release-notes'] - **TiDB Cloud Dedicated** - - 支持将 Flashduty 和 PagerDuty 作为报警/告警订阅渠道。 - - 这些集成旨在简化你的事件管理流程，并提升运维可靠性。 - - 更多信息，参见 [通过 Flashduty 订阅](/tidb-cloud/monitor-alert-flashduty.md) 和 [通过 PagerDuty 订阅](/tidb-cloud/monitor-alert-pagerduty.md)。 + - 支持将 Flashduty 和 PagerDuty 作为告警订阅渠道。 + + 这些集成旨在简化你的事件管理流程并提升运维可靠性。 + + 详情参见 [通过 Flashduty 订阅](/tidb-cloud/monitor-alert-flashduty.md) 和 [通过 PagerDuty 订阅](/tidb-cloud/monitor-alert-pagerduty.md)。 ## 2026 年 1 月 20 日 @@ -64,46 +94,46 @@ aliases: ['/zh/tidbcloud/supported-tidb-versions','/zh/tidbcloud/release-notes'] - **TiDB Cloud Starter** - - 在 [慢查询](/tidb-cloud/tune-performance.md#slow-query) 视图和 [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md) 表中显示真实 client IP 地址（beta）。 + - 在 [慢查询](/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。该功能有助于更准确地识别数据库请求的真实来源，便于排查和分析。 + TiDB Cloud 现已支持客户端 IP 透传，使慢查询视图和 `INFORMATION_SCHEMA.PROCESSLIST` 表能够显示真实客户端 IP 地址，而非负载均衡器（LB）IP。该功能有助于更准确地识别数据库请求的真实来源，便于排查和分析。 - 目前该功能为 beta，仅在 AWS 区域 `Frankfurt (eu-central-1)` 提供。 + 目前，该功能为测试版，仅在 AWS 区域 `Frankfurt (eu-central-1)` 提供。 - **TiDB Cloud Essential** - - 支持数据迁移（beta）。 + - 支持数据迁移（测试版）。 - 你现在可以在 [TiDB Cloud 控制台](https://tidbcloud.com) 使用数据迁移功能，将任意 MySQL 兼容数据库的数据无缝迁移到你的 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群。 + 现在，你可以在 [TiDB Cloud 控制台](https://tidbcloud.com) 使用数据迁移功能，将数据从任意 MySQL 兼容数据库无缝迁移到你的 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 集群。 - 支持的源数据库包括多种 MySQL 兼容系统，如自建 MySQL、Amazon RDS、阿里云 RDS 和 PolarDB。 - 数据迁移支持的连接方式包括公网连接和 PrivateLink，兼顾易用性和企业级安全： - - **公网连接**：通过安全加密通道，快速通过互联网连接到你的源数据库。 + - **公网连接**：通过安全加密通道快速连接到你的源数据库。 - **PrivateLink**：在你的源 VPC 与 TiDB Cloud 之间建立安全私有连接，绕过公网，确保数据隐私和降低网络延时。 目前，数据迁移功能仅支持逻辑模式。 + + 详情参见 [使用数据迁移迁移全量及增量数据](/tidb-cloud/migrate-from-mysql-using-data-migration.md) 和 [使用数据迁移迁移增量数据](/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 地址（beta） + - 在 [慢查询](/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。该功能有助于更准确地识别数据库请求的真实来源，便于排查和分析。 + TiDB Cloud 现已支持客户端 IP 透传，使慢查询视图、数据库审计日志和 `INFORMATION_SCHEMA.PROCESSLIST` 表能够显示真实客户端 IP 地址，而非负载均衡器（LB）IP。该功能有助于更准确地识别数据库请求的真实来源，便于排查和分析。 - 目前该功能为 beta，仅在 AWS 区域 `Frankfurt (eu-central-1)` 提供。 + 目前，该功能为测试版，仅在 AWS 区域 `Frankfurt (eu-central-1)` 提供。 **控制台变更** -- 通过与订阅计划关联的支持选项，提升支持体验。 +- 提升支持体验，提供基于套餐的支持选项。 - [TiDB Cloud 控制台](https://tidbcloud.com/) 现已提供与订阅计划关联的支持选项，提升了所有订阅计划下的支持体验。此次更新包括： + [TiDB Cloud 控制台](https://tidbcloud.com/) 现已提供基于套餐的支持选项，提升所有订阅套餐的支持体验。更新内容包括： - - **与计划关联的支持跳转**：在集群概览页面，点击 **Get Support** 按钮（在 **Actions** 列）会根据你的订阅计划跳转到最相关的资源。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 UI**：重新设计 **Support Plan** 窗口，优先展示你当前订阅计划下可用的支持选项，而非通用计划对比。此更改有助于你快速识别基于当前计划的支持方式。 + - **基于套餐的支持跳转**：在集群概览页面，点击 **Get Support** 按钮后，会根据你的订阅套餐跳转到最相关的资源。Basic 套餐用户会跳转到 **Support Plan** 面板，付费套餐用户会跳转到 **Support Portal**。 + - **优化帮助中心菜单**：将帮助菜单项重命名为 **Support Options** 和 **Support Tickets**，更准确地反映可用服务。新增提示，说明技术支持工单仅对付费套餐开放。 + - **明确社区支持入口**：在 **Support Plan** 选项中，Slack 和 Discord 被明确标识为 Basic 套餐用户的主要技术支持渠道。以下文档已优化，进一步明确支持渠道政策和社区访问方式：[TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)、[Connected Care 概览](/tidb-cloud/connected-care-overview.md) 和 [Connected Care 详情](/tidb-cloud/connected-care-detail.md)。 + - **面向操作的 Support Plan UI**：重新设计 **Support Plan** 窗口，优先展示你当前订阅套餐可用的支持选项，而非通用套餐对比。该变更帮助你快速识别基于当前套餐的支持方式。 - 更多信息，参见 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md)。 + 详情参见 [TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)。 ## 2026 年 1 月 15 日 @@ -111,4 +141,4 @@ aliases: ['/zh/tidbcloud/supported-tidb-versions','/zh/tidbcloud/release-notes'] - **TiDB Cloud Dedicated** - - 将新建 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 集群的默认 TiDB 版本从 [v8.5.4](https://docs.pingcap.com/tidb/stable/release-8.5.4/) 升级到 [v8.5.5](https://docs.pingcap.com/tidb/stable/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/stable/release-8.5.4/) 升级至 [v8.5.5](https://docs.pingcap.com/tidb/stable/release-8.5.5/)。 \ No newline at end of file diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index 8725878a8627d..a57b516937712 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -1,7 +1,7 @@ --- title: "TiDB Cloud Starter 常见问题" summary: 了解与 TiDB Cloud Starter 相关的最常见问题（FAQ）。 -aliases: ['/tidbcloud/serverless-tier-faqs'] +aliases: ['/zh/tidbcloud/serverless-tier-faqs'] --- # TiDB Cloud Starter 常见问题 @@ -14,159 +14,163 @@ aliases: ['/tidbcloud/serverless-tier-faqs'] ### 什么是 TiDB Cloud Starter？ -TiDB Cloud Starter 为你和你的组织提供具备完整 HTAP 能力的 TiDB 数据库。它是 TiDB 的全托管、自动弹性伸缩的部署方式，让你可以立即开始使用数据库，开发和运行应用程序时无需关心底层节点，并且能够根据应用负载变化自动扩缩容。 +TiDB Cloud Starter 为你和你的组织提供具备完整 HTAP 能力的 TiDB 数据库。它是一个全托管、自动扩展的 TiDB 部署，让你可以立即开始使用数据库，开发和运行应用程序，无需关心底层节点，并且能够根据应用负载变化自动扩展。 ### TiDB Cloud Starter 与 TiDB Cloud Serverless 有什么关系？ 自 2025 年 8 月 12 日起，TiDB Cloud Starter 是 TiDB Cloud Serverless 的新名称。 -在更名为 Starter 之前，TiDB Cloud 的 Serverless 层作为数千开发者的入门选择，提供了可自动扩缩容、秒级启动、并且在超出免费额度前无需付费的生产级数据库。 +在更名为 Starter 之前，TiDB Cloud 的 Serverless 层作为数千开发者的入门点，提供了一个可用于生产的数据库，能够自动扩展，几秒内启动，并且在超出大量免费额度前无需付费。 -虽然 “serverless” 能准确反映服务的底层工作方式，但许多首次使用的用户觉得该术语抽象且含义繁杂。 +虽然 “serverless” 准确反映了该服务的工作方式，但许多首次使用的用户觉得这个术语抽象且含义繁杂。 -为了让这个入门层的定位更加清晰，我们将其更名为 Starter，这是使用 TiDB Cloud 构建应用最快捷的方式。你对 Serverless 层的所有认知依然适用： +为了让这个入门层的用途更加清晰，我们将其更名为 Starter，这是使用 TiDB Cloud 构建应用的最快方式。你对 Serverless 层的所有了解依然适用： -- 全托管的数据库，支持行存和列存，适合混合 OLTP 和 OLAP 工作负载。 -- 自动、按需扩缩容，无需容量规划或手动调优。 -- 内置向量检索和全文检索，助力 GenAI 检索、聊天机器人及其他 AI 应用。 -- 每个组织每月最多可免费创建五个集群（每个集群 5 GiB 行存数据 + 5 GiB 列存数据 + 5000 万 [RUs](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)）。 +- 一个全托管的数据库，支持行存和列存，适用于混合 OLTP 和 OLAP 负载。 +- 自动且按需扩展，无需容量规划或手动调优。 +- 内置向量搜索和全文搜索，支持 GenAI 检索、聊天机器人及其他 AI 应用。 +- 每个组织每月最多可免费使用五个集群（每个集群 5 GiB 行存数据 + 5 GiB 列存数据 + 5000 万 [RU](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)）。 ### 如何开始使用 TiDB Cloud Starter？ -请参考 5 分钟上手的 [TiDB Cloud 快速入门](/tidb-cloud/tidb-cloud-quickstart.md)。 +请参考 5 分钟 [TiDB Cloud 快速上手](/tidb-cloud/tidb-cloud-quickstart.md)。 ### 在 TiDB Cloud 中，我最多可以创建多少个 TiDB Cloud Starter 集群？ -在 TiDB Cloud 中，每个组织默认最多可以创建五个 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。如需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并设置 [消费限额](/tidb-cloud/manage-serverless-spend-limit.md)。 +在 TiDB Cloud 中，每个组织默认最多可以创建五个 [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 集群。如需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并设置 [消费上限](/tidb-cloud/manage-serverless-spend-limit.md)。 -### TiDB Cloud Starter 是否完全支持 TiDB Cloud 的所有功能？ +### TiDB Cloud 的所有功能在 TiDB Cloud Starter 上都完全支持吗？ -部分 TiDB Cloud 功能在 TiDB Cloud Starter 上仅部分支持或暂不支持。详细信息请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md)。 +部分 TiDB Cloud 功能在 TiDB Cloud Starter 上仅部分支持或不支持。详情请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md)。 ### TiDB Cloud Starter 何时会支持除 AWS 以外的云平台，如 Google Cloud 或 Azure？ -我们正在积极推进 TiDB Cloud Starter 向 Google Cloud、Azure 等其他云平台的扩展。但目前尚无具体时间表，因为我们当前专注于补齐功能差距并确保各环境下的无缝体验。请放心，我们会持续努力将 TiDB Cloud Starter 推向更多云平台，并在进展过程中及时向社区通报。 +我们正在积极推进 TiDB Cloud Starter 向包括 Google Cloud 和 Azure 在内的其他云平台扩展。但目前尚无具体时间表，因为我们当前专注于补齐功能差距并确保所有环境下的无缝体验。请放心，我们正在努力让 TiDB Cloud Starter 支持更多云平台，并会在进展过程中及时向社区更新。 ### 在 TiDB Cloud Starter 推出前我创建了 Developer Tier 集群，还能继续使用吗？ -可以，你的 Developer Tier 集群已自动迁移为 TiDB Cloud Starter 集群，带来更优的用户体验，且不会影响你之前的使用。 +可以，你的 Developer Tier 集群已自动迁移为 TiDB Cloud Starter 集群，带来更好的用户体验，且不会影响你之前的使用。 ### 什么是 TiDB Cloud Starter 的列存储？ TiDB Cloud Starter 的列存储作为行存储的额外副本，确保强一致性。与传统的行存储（按行存储数据）不同，列存储按列组织数据，优化了数据分析任务。 -列存储是 TiDB 实现 HTAP（混合事务与分析处理）能力的关键特性，实现了事务与分析负载的无缝融合。 +列存储是实现 TiDB HTAP (Hybrid Transactional and Analytical Processing) 能力的关键特性，通过无缝融合事务型和分析型负载。 -为高效管理列存储数据，TiDB Cloud Starter 使用独立的弹性 TiFlash 引擎。在查询执行时，优化器会自动引导集群决定从行存还是列存读取数据。 +为高效管理列存储数据，TiDB Cloud Starter 使用独立的弹性 TiFlash 引擎。在查询执行过程中，优化器会自动引导集群决定从行存储还是列存储读取数据。 -### 在哪些场景下应使用 TiDB Cloud Starter 的列存储？ +### 在 TiDB Cloud Starter 中，什么时候应该使用列存储？ -在以下场景下建议使用 TiDB Cloud Starter 的列存储： +在以下场景中建议使用 TiDB Cloud Starter 的列存储： -- 你的工作负载包含需要高效数据扫描和聚合的分析任务。 -- 你优先考虑分析型负载的性能提升。 -- 你希望将分析处理与事务处理隔离，避免对 TP（事务处理）负载产生性能影响。独立的列存储有助于优化不同类型的负载模式。 +- 你的负载包含需要高效数据扫描和聚合的分析型任务。 +- 你优先考虑提升分析型负载的性能。 +- 你希望将分析处理与事务处理隔离，避免对 TP 负载产生性能影响。独立的列存储有助于优化不同的负载模式。 -在这些场景下，列存储可以显著提升查询性能，为系统中的混合负载带来流畅体验。 +在这些场景下，列存储可以显著提升查询性能，为系统中的混合负载带来无缝体验。 ### 如何在 TiDB Cloud Starter 中使用列存储？ -在 TiDB Cloud Starter 中使用列存储的方式与 TiFlash 类似。你可以在表级或数据库级启用列存储： +在 TiDB Cloud Starter 中使用列存储与 TiFlash 的用法类似。你可以在表级和数据库级启用列存储： - 表级：为某个表分配 TiFlash 副本，为该表启用列存储。 -- 数据库级：为数据库内所有表配置 TiFlash 副本，实现全库的列存储。 +- 数据库级：为数据库内所有表配置 TiFlash 副本，实现整个数据库的列存储。 -为表设置 TiFlash 副本后，TiDB 会自动将该表的行存数据同步到列存，确保数据一致性并优化分析型查询性能。 +为表设置 TiFlash 副本后，TiDB 会自动将该表的数据从行存储同步到列存储，确保数据一致性并优化分析型查询的性能。 关于如何设置 TiFlash 副本，详见 [创建 TiFlash 副本](/tiflash/create-tiflash-replicas.md)。 -### 为什么我的连接在空闲几分钟后会断开？ +### 为什么我的连接在空闲几分钟后被断开？ -当你通过 Public Endpoint 连接时，连接会经过多个网络服务商和中间设备。这些设备可能有较短的空闲超时时间，导致连接被提前中断。更多信息请参见 [连接限制](/tidb-cloud/serverless-limitations.md#connection)。 +当你通过 Public Endpoint 连接时，连接会经过多个网络服务商和中间设备。这些设备可能有较短的空闲超时时间，导致连接被提前中断。详情请参见 [连接限制](/tidb-cloud/serverless-limitations.md#connection)。 + +### 为什么会收到 “Connection limit exceeded” 错误？ + +当你的集群超过最大并发连接数限制时，会出现该错误。详情请参见 [连接限制](/tidb-cloud/serverless-limitations.md#connection)。 ## 计费与计量常见问题 ### 什么是 Request Units？ -TiDB Cloud Starter 采用按需付费模式，你只需为存储空间和集群使用量付费。在该模式下，所有集群活动（如 SQL 查询、批量操作、后台任务）都以 [Request Units（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) 计量。RU 是对集群请求规模和复杂度的抽象度量。详细信息请参见 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 +TiDB Cloud Starter 采用按需付费模式，即你只需为存储空间和集群使用量付费。在该模式下，所有集群活动（如 SQL 查询、批量操作和后台作业）都以 [Request Units (RU)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) 进行量化。RU 是对集群上发起的请求规模和复杂度的抽象度量。详情请参见 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 ### TiDB Cloud Starter 是否有免费计划？ -对于你所在组织的前五个 TiDB Cloud Starter 集群，TiDB Cloud 为每个集群提供如下免费额度： +对于组织内前五个 TiDB Cloud Starter 集群，TiDB Cloud 为每个集群提供如下免费额度： - 行存储：5 GiB - 列存储：5 GiB -- [Request Units（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)：每月 5000 万 RUs +- [Request Units (RU)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)：每月 5000 万 RU -如果为 TiDB Cloud Starter 集群设置了每月消费限额，超出免费额度的部分将会计费。对于免费集群，达到免费额度后，该集群的读写操作将被限流，直到你设置每月消费限额或新月开始时额度重置。 +如果为 TiDB Cloud Starter 集群设置了每月消费上限，超出免费额度的部分将会计费。对于免费集群，达到免费额度后，该集群的读写操作将被限流，直到你设置每月消费上限或新月开始时用量被重置。 -更多信息请参见 [TiDB Cloud Starter 使用额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 +详情请参见 [TiDB Cloud Starter 使用额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 ### 免费计划有哪些限制？ -在免费计划下，集群性能受限于不可扩展的资源。每个查询的内存分配被限制为 256 MiB，并可能出现每秒 RUs 的瓶颈。为最大化集群性能并避免这些限制，你可以为 TiDB Cloud Starter 集群 [设置每月消费限额](/tidb-cloud/manage-serverless-spend-limit.md)。 +在免费计划下，集群性能受限于不可扩展的资源。每个查询的内存分配被限制为 256 MiB，并可能导致每秒 Request Units (RU) 出现瓶颈。为最大化集群性能并避免这些限制，你可以为 TiDB Cloud Starter 集群 [设置每月消费上限](/tidb-cloud/manage-serverless-spend-limit.md)。 -### 如何评估我的工作负载所需的 RUs 数量并规划每月预算？ +### 如何评估我的负载所需的 RU 数量并规划每月预算？ -你可以使用 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md#ru-request-unit-consumption) SQL 语句获取单条 SQL 的 RU 消耗。但需要注意，`EXPLAIN ANALYZE` 返回的 RUs 使用量不包含出口流量的 RUs，因为出口流量在网关单独计量，TiDB 服务器无法获知。 +要获取单条 SQL 语句的 RU 消耗，可以使用 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md#ru-request-unit-consumption) SQL 语句。但需要注意，`EXPLAIN ANALYZE` 返回的 RU 用量不包含出口 RU，因为出口用量在网关单独计量，TiDB 服务器无法获知。 -要查看集群的 RUs 和存储用量，请在集群概览页查看 **Usage this month** 面板。结合历史和实时资源使用数据，你可以跟踪集群资源消耗并合理预估消费限额。如果免费额度无法满足需求，你可以调整消费限额以获取更多资源。更多信息请参见 [TiDB Cloud Starter 使用额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 +要查看集群的 RU 和存储用量，请在集群概览页面查看 **Usage this month** 面板。结合历史资源用量和该面板的实时用量数据，你可以跟踪集群资源消耗并合理预估消费上限。如果免费额度无法满足需求，你可以编辑消费上限以获取更多资源。详情请参见 [TiDB Cloud Starter 使用额度](/tidb-cloud/select-cluster-tier.md#usage-quota)。 -### 如何优化我的工作负载以减少 RUs 消耗？ +### 如何优化我的负载以减少 RU 消耗？ -请按照 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md) 指南优化查询，确保最佳性能。要识别消耗 RUs 最多的 SQL 语句，可前往集群的 [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页面，查看 **SQL Statements** 标签页，按 **Total RU** 或 **Mean RU** 排序，分析 SQL 执行情况。更多信息请参见 [语句分析](/tidb-cloud/tune-performance.md#statement-analysis)。此外，减少出口流量同样有助于降低 RUs 消耗。建议查询时仅返回必要的列和行，通过精确选择和过滤返回数据，优化网络利用率。 +请确保你的查询已根据 [优化 SQL 性能](/develop/dev-guide-optimize-sql-overview.md) 指南进行优化，以获得最佳性能。要识别消耗 RU 最多的 SQL 语句，可进入集群的 [**诊断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) 页面，查看 **SQL Statements** 标签页，在此可观察 SQL 执行并按 **Total RU** 或 **Mean RU** 排序查看高消耗语句。详情请参见 [语句分析](/tidb-cloud/tune-performance.md#statement-analysis)。此外，减少出口流量对于降低 RU 消耗也很重要。建议在查询中仅返回必要的列和行，从而减少网络出口流量。通过精确选择和过滤返回的列与行，可以优化网络利用率。 ### TiDB Cloud Starter 的存储如何计量？ -存储计量基于 TiDB Cloud Starter 集群中存储的数据量，以 GiB/月为单位。计算方式为：所有表和索引的总大小（不含数据压缩或副本）乘以当月数据存储的小时数。 +存储计量基于 TiDB Cloud Starter 集群中存储的数据量，以 GiB/月为单位。计算方式为：所有表和索引的总大小（不含数据压缩或副本）乘以该月内数据存储的小时数。 -### 为什么删除表或数据库后存储用量没有立即变化？ +### 为什么在立即删除表或数据库后，存储用量没有变化？ -这是因为 TiDB 会在一段时间内保留已删除的表和数据库。该保留期确保依赖这些表的事务可以继续执行。此外，保留期也使 [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)/[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md) 功能成为可能，便于你在误删时恢复表和数据库。 +这是因为 TiDB 会在一段保留时间内保留已删除的表和数据库。该保留时间确保依赖这些表的事务可以继续执行不受影响。此外，保留时间也使 [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)/[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md) 功能成为可能，允许你在误删时恢复表和数据库。 -### 为什么在没有主动运行查询时也会有 RU 消耗？ +### 为什么在没有主动运行查询时仍有 RU 消耗？ -RU 消耗可能出现在多种场景。常见场景包括后台查询，如在 TiDB 实例间同步模式变更、执行 DDL 任务、刷新权限、刷新 SQL 绑定、刷新全局变量等。另一个场景是 Web 控制台的某些功能会生成查询（如加载 schema）。这些过程即使没有用户主动触发，也会消耗 RUs。 +RU 消耗可能出现在多种场景。常见场景包括后台查询，如在 TiDB 实例间同步 schema 变更、执行 DDL 作业、刷新权限、刷新 SQL 绑定和刷新全局变量。另一个场景是某些 Web 控制台功能会生成查询，如加载 schema。这些过程即使没有用户显式触发，也会消耗 RU。 -### 为什么在工作负载稳定时会出现 RU 使用量的突增？ +### 为什么在负载稳定时 RU 用量会出现突增？ -RU 使用量突增可能由 TiDB 的必要后台任务引起，如自动分析表和重建统计信息，这些任务有助于生成优化的查询计划。 +RU 用量突增可能是由于 TiDB 必要的后台作业引起。这些作业（如自动分析表和重建统计信息）用于生成优化的查询计划。 -### 当集群用尽免费额度或超出消费限额时会发生什么？ +### 当集群用尽免费额度或超出消费上限时会发生什么？ -一旦集群达到免费额度或消费限额，系统会立即拒绝所有新的连接请求，直到额度提升或新月开始时用量重置。已建立的连接会继续保持，但会受到限流。更多信息请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md#usage-quota)。 +当集群达到免费额度或消费上限后，系统会立即拒绝任何新的连接请求，直到额度提升或新月开始时用量被重置。已建立的连接会保持活跃，但会被限流。详情请参见 [TiDB Cloud Starter 限制与配额](/tidb-cloud/serverless-limitations.md#usage-quota)。 -### 为什么导入数据时 RU 使用量会出现突增？ +### 为什么在导入数据时 RU 用量会出现突增？ -在 TiDB Cloud Starter 集群的数据导入过程中，只有数据成功导入时才会消耗 RUs，因此会出现 RU 使用量的突增。 +在 TiDB Cloud Starter 集群的数据导入过程中，只有数据成功导入时才会产生 RU 消耗，因此会导致 RU 用量突增。 ### 在 TiDB Cloud Starter 中使用列存储会产生哪些费用？ -TiDB Cloud Starter 的列存储计费方式与行存储类似。启用列存储时，会额外创建一个副本用于存储数据（不含索引）。从行存到列存的数据同步不会产生额外费用。 +TiDB Cloud Starter 的列存储计费方式与行存储类似。使用列存储时，会额外创建一个副本用于存储数据（不含索引）。从行存储到列存储的数据同步不会产生额外费用。 详细价格信息请参见 [TiDB Cloud Starter 价格详情](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 -### 使用列存储会更贵吗？ +### 使用列存储是否更贵？ -TiDB Cloud Starter 的列存储由于额外副本，会产生更多存储和数据同步资源消耗，因此成本略高。但在运行分析型查询时，列存储更具性价比。 +TiDB Cloud Starter 的列存储由于额外副本，会产生更多存储和数据同步资源消耗，因此成本更高。但在运行分析型查询时，列存储更具性价比。 根据 TPC-H 基准测试，在列存储上运行分析型查询的成本约为行存储的三分之一。 -因此，虽然初期因副本增加带来一定成本，但分析场景下的计算成本大幅降低，使其在特定用例下更具成本优势。尤其对于有分析需求的用户，列存储可显著降低成本，带来可观的节省空间。 +因此，虽然初期因额外副本会有一定成本，但分析型查询时的计算成本降低，使其在特定场景下更具成本优势。尤其对于有分析需求的用户，列存储可显著降低成本，带来可观的节省空间。 ## 安全性常见问题 ### 我的 TiDB Cloud Starter 是共享还是专用的？ -Serverless 技术为多租户设计，所有集群的资源均为共享。如需获得基础设施和资源隔离的托管 TiDB 服务，你可以升级为 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)。 +Serverless 技术采用多租户技术，所有集群使用的资源是共享的。如需获得基础设施和资源隔离的托管 TiDB 服务，你可以升级到 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)。 ### TiDB Cloud Starter 如何保障安全性？ -- 你的连接通过 TLS（传输层安全协议）加密。关于如何使用 TLS 连接 TiDB Cloud Starter，详见 [TLS 连接到 TiDB Cloud Starter](/tidb-cloud/secure-connections-to-serverless-clusters.md)。 +- 你的连接通过 Transport Layer Security (TLS) 加密。关于如何使用 TLS 连接 TiDB Cloud Starter，详见 [TLS 连接到 TiDB Cloud Starter](/tidb-cloud/secure-connections-to-serverless-clusters.md)。 - TiDB Cloud Starter 上所有持久化数据均采用集群所在云服务商的工具进行静态加密。 ## 运维常见问题 -### 我可以升级集群所运行的 TiDB 版本吗？ +### 我可以升级集群运行的 TiDB 版本吗？ -不可以。TiDB Cloud Starter 集群会随着 TiDB Cloud 推出新版本自动升级。你可以在 [TiDB Cloud 控制台](https://tidbcloud.com/project/clusters) 或最新的 [发布说明](https://docs.pingcap.com/tidbcloud/tidb-cloud-release-notes) 查看集群当前的 TiDB 版本。你也可以连接到集群，使用 `SELECT version()` 或 `SELECT tidb_version()` 查询 TiDB 版本。 \ No newline at end of file +不可以。TiDB Cloud Starter 集群会随着我们在 TiDB Cloud 上发布新版本自动升级。你可以在 [TiDB Cloud 控制台](https://tidbcloud.com/project/clusters) 或最新 [发布说明](https://docs.pingcap.com/tidbcloud/tidb-cloud-release-notes) 查看集群当前运行的 TiDB 版本。你也可以连接到集群，使用 `SELECT version()` 或 `SELECT tidb_version()` 查询 TiDB 版本。 \ No newline at end of file diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index aa79d1c3b20e1..fec550da37f04 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -1,16 +1,16 @@ --- title: TiDB Cloud Starter 和 Essential 的限制与配额 summary: 了解 TiDB Cloud Starter 的限制。 -aliases: ['/tidbcloud/serverless-tier-limitations'] +aliases: ['/zh/tidbcloud/serverless-tier-limitations'] --- # TiDB Cloud Starter 和 Essential 的限制与配额 -TiDB Cloud Starter 和 TiDB Cloud Essential 支持几乎所有 TiDB 支持的 workload，但与 TiDB 自主管理版或 TiDB Cloud Dedicated 集群相比，存在一些功能差异。本文档介绍了 TiDB Cloud Starter 和 TiDB Cloud Essential 的限制。 +TiDB Cloud Starter 和 TiDB Cloud Essential 支持几乎所有 TiDB 支持的 workload，但与 TiDB Self-Managed 或 TiDB Cloud Dedicated 集群相比，存在一些功能差异。本文档介绍了 TiDB Cloud Starter 和 TiDB Cloud Essential 的限制。 -我们正在不断弥补 TiDB Cloud Starter/Essential 与 TiDB Cloud Dedicated 之间的功能差距。如果你需要这些缺失的功能或能力，请使用 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 或 [联系我们](https://www.pingcap.com/contact-us/?from=en) 提交功能需求。 +我们正在不断缩小 TiDB Cloud Starter/Essential 与 TiDB Cloud Dedicated 之间的功能差距。如果你需要这些缺失的功能或能力，请使用 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 或 [联系我们](https://www.pingcap.com/contact-us/?from=en) 提交功能需求。 ## 限制 @@ -20,9 +20,10 @@ TiDB Cloud Starter 和 TiDB Cloud Essential 支持几乎所有 TiDB 支持的 wo ### 连接 -- 仅支持 [Public Endpoint](/tidb-cloud/connect-via-standard-connection-serverless.md) 和 [Private Endpoint](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)。你无法使用 [VPC Peering](/tidb-cloud/set-up-vpc-peering-connections.md) 连接 TiDB Cloud Starter 或 TiDB Cloud Essential 集群。 +- 仅支持 [Public Endpoint](/tidb-cloud/connect-via-standard-connection-serverless.md) 和 [Private Endpoint](/tidb-cloud/set-up-private-endpoint-connections-serverless.md) 连接。你无法使用 [VPC Peering](/tidb-cloud/set-up-vpc-peering-connections.md) 连接到 TiDB Cloud Starter 或 TiDB Cloud Essential 集群。 - Private Endpoint 不支持 [Firewall Rules](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)。 -- 如果你的数据库 client 连接保持打开超过 30 分钟，可能会被意外断开。这可能发生在 TiDB server 关闭、restart 或维护期间，可能导致应用程序中断。为避免此问题，请配置最大连接生命周期。建议从 5 分钟开始，如果影响 tail latency 再逐步增加。更多信息参见 [连接池推荐设置](/develop/dev-guide-connection-parameters.md)。 +- 如果你的数据库 client 连接保持打开超过 30 分钟，可能会被意外断开。这种情况可能发生在 TiDB server 关闭、restart 或维护期间，可能导致应用程序中断。为避免此问题，请配置最大连接生命周期。建议从 5 分钟开始，如果影响 tail latency 可逐步增加。更多信息参见 [连接池推荐设置](/develop/dev-guide-connection-parameters.md)。 +- 对于 TiDB Cloud Starter 集群，最多支持 400 个并发连接。如果你设置了 [spending limit](/tidb-cloud/manage-serverless-spend-limit.md)，此限制提升至 5,000。 > **注意：** > @@ -30,7 +31,7 @@ TiDB Cloud Starter 和 TiDB Cloud Essential 支持几乎所有 TiDB 支持的 wo ### 加密 -- 持久化在 TiDB Cloud Starter 或 TiDB Cloud Essential 集群中的数据，使用管理你集群的云服务商提供的加密工具进行加密。对于 TiDB Cloud Starter（spending limit > 0）和 TiDB Cloud Essential 集群，在集群创建过程中可选择启用第二层加密，为默认静态加密之外提供额外的安全保障。 +- 你在 TiDB Cloud Starter 或 TiDB Cloud Essential 集群中持久化的数据，使用管理你集群的云服务商提供的加密工具进行加密。对于 TiDB Cloud Starter（spending limit > 0）和 TiDB Cloud Essential 集群，在集群创建过程中可选择启用第二层加密，为默认静态加密之外提供额外的安全保障。 - 目前不支持使用 [customer-managed encryption keys (CMEK)](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)。 ### 维护窗口 @@ -45,12 +46,12 @@ TiDB Cloud Starter 和 TiDB Cloud Essential 支持几乎所有 TiDB 支持的 wo ### 自助升级 -- TiDB Cloud Starter 和 TiDB Cloud Essential 是完全托管的 TiDB 部署。其主版本和小版本升级由 TiDB Cloud 负责，用户无法自行发起升级。 +- TiDB Cloud Starter 和 TiDB Cloud Essential 是完全托管的 TiDB 部署。TiDB Cloud Starter 和 TiDB Cloud Essential 的主版本和小版本升级由 TiDB Cloud 负责，用户无法自行发起升级。 ### 流式数据 - TiDB Cloud Starter 目前不支持 [Changefeed](/tidb-cloud/changefeed-overview.md)。 -- TiDB Cloud Starter 目前不支持 [Data Migration](/tidb-cloud/migrate-from-mysql-using-data-migration.md)。 +- TiDB Cloud Starter 目前不支持 [数据迁移](/tidb-cloud/migrate-from-mysql-using-data-migration.md)。 ### 生存时间（TTL） @@ -58,25 +59,25 @@ TiDB Cloud Starter 和 TiDB Cloud Essential 支持几乎所有 TiDB 支持的 wo ### 其他 -- transaction 最长不能超过 30 分钟。 +- 事务不能持续超过 30 分钟。 - 更多 SQL 限制详情，参见 [Limited SQL Features](/tidb-cloud/limited-sql-features.md)。 ## 使用配额 -在 TiDB Cloud 的每个组织下，默认最多可创建 5 个 [免费 TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#starter)。如需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并为使用量 [设置每月消费上限](/tidb-cloud/manage-serverless-spend-limit.md)。 +在 TiDB Cloud 的每个组织下，默认最多可创建 5 个 [免费 TiDB Cloud Starter 集群](/tidb-cloud/select-cluster-tier.md#starter)。如需创建更多 TiDB Cloud Starter 集群，你需要添加信用卡并为使用设置 [每月 spending limit](/tidb-cloud/manage-serverless-spend-limit.md)。 对于组织中的前 5 个 TiDB Cloud Starter 集群，TiDB Cloud 为每个集群提供如下免费使用配额： - 行存储：5 GiB - 列存储：5 GiB -- [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)：每月 5000 万 RUs +- [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)：每月 5,000 万 RU -Request Unit (RU) 是用于衡量 query 或 transaction 资源消耗的单位。它是一种指标，可以帮助你估算数据库处理特定 request 所需的计算资源。request unit 也是 TiDB Cloud Starter service 的计费单位。 +Request Unit (RU) 是用于衡量 query 或 transaction 资源消耗的单位。它是一种指标，可以帮助你估算处理特定 request 在数据库中所需的计算资源。request unit 也是 TiDB Cloud Starter service 的计费单位。 -当集群达到其使用配额后，将立即拒绝所有新的连接尝试，直到你 [增加配额](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit) 或新月开始时用量重置。已建立的连接在达到配额前会保持活跃，但会受到限流。 +一旦集群达到其使用配额，将立即拒绝所有新的连接尝试，直到你 [提升配额](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit) 或新月开始时用量被重置。已建立的连接在达到配额前会保持活跃，但会受到限流。 -如需了解不同资源（包括 read、write、SQL CPU 和网络出流量）的 RU 消耗、定价详情及限流信息，请参见 [TiDB Cloud Starter Pricing Details](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 +如需了解不同资源（包括 read、write、SQL CPU 和网络出口）的 RU 消耗、定价详情及限流信息，请参见 [TiDB Cloud Starter Pricing Details](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)。 -如果你希望为 TiDB Cloud Starter 集群设置额外配额，可以在集群创建页面设置每月消费上限。更多信息参见 [创建 TiDB Cloud Starter 集群](/tidb-cloud/create-tidb-cluster-serverless.md)。 +如果你希望创建配额更高的 TiDB Cloud Starter 集群，可以在集群创建页面设置每月 spending limit。更多信息参见 [创建 TiDB Cloud Starter 集群](/tidb-cloud/create-tidb-cluster-serverless.md)。 -创建 TiDB Cloud Starter 集群后，你仍可在集群概览页面查看和 edit 消费上限。更多信息参见 [管理 TiDB Cloud Starter 集群的消费上限](/tidb-cloud/manage-serverless-spend-limit.md)。 \ No newline at end of file +创建 TiDB Cloud Starter 集群后，你仍可在集群概览页面查看和 edit spending limit。更多信息参见 [管理 TiDB Cloud Starter 集群的 Spending Limit](/tidb-cloud/manage-serverless-spend-limit.md)。 \ No newline at end of file diff --git a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md new file mode 100644 index 0000000000000..e83b32fe7fe54 --- /dev/null +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -0,0 +1,157 @@ +--- +title: 通过 Private Link 连接访问 Amazon MSK Provisioned +summary: 了解如何使用 Amazon MSK Provisioned Private Link 连接访问 Amazon MSK Provisioned 集群。 +--- + +# 通过 Private Link 连接访问 Amazon MSK Provisioned + +本文档介绍如何通过 [Amazon MSK Provisioned Private Link 连接](/tidb-cloud/serverless-private-link-connection.md#create-an-amazon-msk-provisioned-private-link-connection) 将 TiDB Cloud Essential 集群连接到 [Amazon MSK Provisioned](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provisioned.html) 集群。 + +## TiDB Cloud Essential 的前置条件 {#prerequisites-for-essential} + +- 你的 TiDB Cloud Essential 集群已托管在 AWS 上并处于活跃状态。请获取并保存以下信息以备后续使用： + + - AWS 账户 ID + - 可用区（AZ） + +查看 AWS 账户 ID 和可用区的方法如下： + +1. 在 [TiDB Cloud 控制台](https://tidbcloud.com)中，进入你的 TiDB 集群的集群总览页面，然后点击左侧导航栏的 **Settings** > **Networking**。 +2. 在 **Private Link Connection For Dataflow** 区域，点击 **Create Private Link Connection**。 +3. 在弹窗中，记录 AWS 账户 ID 和可用区信息。 + +## Amazon MSK Provisioned 集群的前置条件 + +在开始之前，请确保你的 Amazon MSK Provisioned 集群满足以下条件： + +- **Region 和可用区**：你的 Amazon MSK Provisioned 集群与 TiDB Cloud Essential 集群处于同一个 AWS Region，且 MSK 集群的可用区与 TiDB Cloud 集群一致。 +- **认证方式**：MSK 集群必须启用 [SASL/SCRAM 认证](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html)。 +- **Broker 类型**：不要使用 `t4.small` broker 类型，该类型不支持 Private Link。 + +更多要求请参见 [Amazon MSK 单 Region 多 VPC 私有连接要求](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-requirements)。 + +如果你还没有 Amazon MSK Provisioned 集群，请在与你的 TiDB Cloud Essential 集群相同的 Region 和可用区 [创建一个集群](https://docs.aws.amazon.com/msk/latest/developerguide/create-cluster.html)，并为新建的集群 [配置 SASL/SCRAM 认证](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html)。 + +- **Secret 名称**：secret 名称必须以 `AmazonMSK_` 开头。 +- **加密**：不要使用默认加密密钥。请为你的 secret 创建新的自定义 AWS KMS 密钥。 + +## 步骤 1. 为 TiDB Cloud 访问配置 Kafka ACL + +你必须配置 Kafka ACL，以便 TiDB Cloud 能够访问你的 Amazon MSK Provisioned 集群。你可以使用 SASL/SCRAM 认证（推荐）或 IAM 认证来配置 ACL。 + + +
+ +使用此方法，在与你的 MSK 集群相同的 VPC 内，通过 SASL/SCRAM 认证创建 ACL。 + +1. 在 MSK 集群所在的 VPC 内创建一台 EC2 实例（Linux），并通过 SSH 连接到该实例。 + +2. 下载 Kafka 和 OpenJDK： + + ```shell + wget https://archive.apache.org/dist/kafka/3.7.1/kafka_2.13-3.7.1.tgz + tar -zxf kafka_2.13-3.7.1.tgz + wget https://download.java.net/java/GA/jdk22.0.2/c9ecb94cd31b495da20a27d4581645e8/9/GPL/openjdk-22.0.2_linux-x64_bin.tar.gz + tar -zxf openjdk-22.0.2_linux-x64_bin.tar.gz + ``` + +3. 配置环境变量。请将路径替换为你的实际路径。 + + ```shell + export PATH=$PATH:/home/ec2-user/jdk-22.0.2/bin + ``` + +4. 创建名为 `scram-client.properties` 的文件，并写入以下内容。将 `username` 和 `pswd` 替换为你的 SASL/SCRAM 凭证： + + ```properties + security.protocol=SASL_SSL + sasl.mechanism=SCRAM-SHA-512 + sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \ + username="username" \ + password="pswd"; + ``` + +5. 创建 ACL。将 `bootstrap-server` 替换为你的 MSK 启动服务器地址和端口（例如，`b-2.xxxxx.c18.kafka.us-east-1.amazonaws.com:9096`），如有需要也请替换 Kafka 路径： + + ```shell + /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config scram-client.properties --add --allow-principal User: --operation All --topic '*' + /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config scram-client.properties --add --allow-principal User: --operation All --group '*' + /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config scram-client.properties --add --allow-principal User: --operation All --cluster '*' + ``` + + 其中 principal `User:` 是 TiDB Cloud 用于访问你的 MSK 集群的 SASL/SCRAM 用户。请使用你在 MSK ACL 中为 TiDB Cloud 配置的用户名。 + +
+ +
+ +作为 SASL/SCRAM 的替代方案，你也可以在 MSK 集群所在的 VPC 内，通过 IAM 认证创建 ACL。IAM 用户或角色必须拥有 **Amazon MSK** 和 **Apache Kafka APIs for MSK** 权限。 + +1. 在 MSK 集群所在的 VPC 内创建一台 EC2 实例（Linux），并通过 SSH 连接到该实例。 + +2. 下载 Kafka、OpenJDK 以及 AWS MSK IAM 认证 JAR 包： + + ```shell + wget https://archive.apache.org/dist/kafka/3.7.1/kafka_2.13-3.7.1.tgz + tar -zxf kafka_2.13-3.7.1.tgz + wget https://download.java.net/java/GA/jdk22.0.2/c9ecb94cd31b495da20a27d4581645e8/9/GPL/openjdk-22.0.2_linux-x64_bin.tar.gz + tar -zxf openjdk-22.0.2_linux-x64_bin.tar.gz + wget https://github.com/aws/aws-msk-iam-auth/releases/download/v2.3.5/aws-msk-iam-auth-2.3.5-all.jar + ``` + +3. 配置环境变量。请将路径和凭证替换为你自己的值。 + + ```shell + export PATH=$PATH:/home/ec2-user/jdk-22.0.2/bin + export CLASSPATH=/home/ec2-user/aws-msk-iam-auth-2.3.5-all.jar + export AWS_ACCESS_KEY_ID= + export AWS_SECRET_ACCESS_KEY= + ``` + +4. 创建名为 `iam-client.properties` 的文件，并写入以下内容： + + ```properties + security.protocol=SASL_SSL + sasl.mechanism=AWS_MSK_IAM + sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required; + sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler + ``` + +5. 创建 ACL。将 `bootstrap-server` 替换为你的 MSK 启动服务器地址和端口（例如，`b-1.xxxxx.c18.kafka.us-east-1.amazonaws.com:9098`），如有需要也请替换 Kafka 路径： + + ```shell + /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config iam-client.properties --add --allow-principal User: --operation All --topic '*' + /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config iam-client.properties --add --allow-principal User: --operation All --group '*' + /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config iam-client.properties --add --allow-principal User: --operation All --cluster '*' + ``` + + 其中 principal `User:` 是 TiDB Cloud 用于访问你的 MSK 集群的 SASL/SCRAM 用户。请使用你在 MSK ACL 中为 TiDB Cloud 配置的用户名。 + +
+ + +## 步骤 2. 配置 MSK 集群 + +更新以下集群配置属性： + +- 设置 `auto.create.topics.enable=true`。 +- 添加 `allow.everyone.if.no.acl.found=false`（SASL/SCRAM 必需）。 +- 其他属性保持不变或根据需要调整。 + +应用更改后，等待集群状态从 **Updating** 变为 **Active**。 + +## 步骤 3. 关联集群策略 + +[关联集群策略](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-policy.html)，以允许 TiDB Cloud 连接你的 MSK 集群。请使用你在 [前置条件](#prerequisites-for-essential) 中获取的 TiDB Cloud AWS 账户 ID。 + +## 步骤 4. 开启多 VPC 连接 + +集群变为活跃后，为 MSK 集群 [开启多 VPC 连接](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-turn-on.html)。AWS PrivateLink 需要开启多 VPC 连接。要从 TiDB Cloud 连接，必须启用 SASL/SCRAM 认证。 + +等待集群状态再次从 **Updating** 变为 **Active**。 + +## 步骤 5. 在 TiDB Cloud 中创建 Amazon MSK Provisioned Private Link 连接 + +使用你的 MSK 集群的 `ARN`，在 TiDB Cloud 中创建 Private Link 连接。 + +更多信息请参见 [创建 Amazon MSK Provisioned Private Link 连接](/tidb-cloud/serverless-private-link-connection.md#create-an-amazon-msk-provisioned-private-link-connection)。 \ No newline at end of file diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index d0d16a980ef2f..3629a395b3106 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -7,23 +7,27 @@ summary: 了解如何为 Dataflow 设置私有链路连接。 TiDB Cloud 中的数据流服务（如 Changefeed 和 Data Migration (DM)）需要与外部资源（如 RDS 实例和 Kafka 集群）建立可靠的连接。虽然支持公网端点，但私有链路连接提供了更优的选择，具有效率更高、延时更低和安全性更强的优势。 -私有链路连接可以在 TiDB Cloud Essential 与你的目标资源之间建立直接连接。这确保了从 TiDB Cloud 到你在其他云平台上的数据库的数据始终在私有网络边界内传输，大幅降低了网络攻击面，并为关键数据流工作负载提供了稳定的吞吐。 +私有链路连接能够在 TiDB Cloud Essential 与目标资源之间建立直接连接。这确保了从 TiDB Cloud 到你在其他云平台上的数据库的数据始终在私有网络边界内传输，大幅降低了网络攻击面，并为关键数据流工作负载提供了稳定的吞吐。 ## 私有链路连接类型 -数据流的私有链路连接有多种类型，具体取决于云服务商和你要访问的服务。每种类型都能在你的 TiDB Cloud 集群与同一云环境中的外部资源（如 RDS 或 Kafka）之间实现安全、私有的网络访问。 +Dataflow 的私有链路连接有多种类型，具体取决于云服务商和你要访问的服务。每种类型都能在你的 TiDB Cloud 集群与同一云环境中的外部资源（如 RDS 或 Kafka）之间实现安全、私有的网络访问。 ### AWS Endpoint Service -此类型的私有链路连接允许部署在 **AWS** 上的 TiDB Cloud 集群连接到你基于 AWS PrivateLink 的 [AWS endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)。 +此类型的私有链路连接允许部署在 **AWS** 上的 TiDB Cloud 集群连接到你的 [AWS endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)，该服务由 AWS PrivateLink 提供支持。 -通过将 AWS 各类服务（如 RDS 实例和 Kafka 服务）与 endpoint service 关联，私有链路连接即可访问这些服务。 +通过将 RDS 实例和 Kafka 服务等 AWS 服务与 endpoint service 关联，私有链路连接即可访问这些服务。 + +### Amazon MSK Provisioned + +此类型的私有链路连接允许部署在 **AWS** 上的 TiDB Cloud 集群通过私有链路连接到你的 [Amazon MSK Provisioned](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provisioned.html)。 ### 阿里云 Endpoint Service -此类型的私有链路连接允许部署在 **阿里云** 上的 TiDB Cloud 集群连接到你基于阿里云 PrivateLink 的 [阿里云 endpoint service](https://www.alibabacloud.com/help/en/privatelink/share-your-service/#51976edba8no7)。 +此类型的私有链路连接允许部署在 **阿里云** 上的 TiDB Cloud 集群连接到你的 [阿里云 endpoint service](https://www.alibabacloud.com/help/en/privatelink/share-your-service/#51976edba8no7)，该服务由阿里云 PrivateLink 提供支持。 -通过将阿里云各类服务（如 RDS 实例和 Kafka 服务）与 endpoint service 关联，私有链路连接即可访问这些服务。 +通过将 RDS 实例和 Kafka 服务等阿里云服务与 endpoint service 关联，私有链路连接即可访问这些服务。 ## 创建 AWS Endpoint Service 私有链路连接 @@ -44,7 +48,7 @@ ticloud serverless private-link-connection zones --cluster-id
-1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 +1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，并进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > @@ -54,7 +58,7 @@ ticloud serverless private-link-connection zones --cluster-id 3. 在 **Private Link Connection For Dataflow** 区域，点击 **Create Private Link Connection**。 -4. 在 **Create Private Link Connection** 对话框中，填写所需信息： +4. 在 **Create Private Link Connection** 对话框中，填写以下信息： - **Private Link Connection Name**：输入私有链路连接的名称。 - **Connection Type**：选择 **AWS Endpoint Service**。如果未显示该选项，请确保你的集群部署在 AWS 上。 @@ -81,6 +85,30 @@ ticloud serverless private-link-connection zones --cluster-id
+## 创建 Amazon MSK Provisioned 私有链路连接 + +你可以通过 TiDB Cloud 控制台创建 Amazon MSK Provisioned 私有链路连接。 + +在创建 Amazon MSK Provisioned 私有链路连接前，请确保你的 Amazon MSK Provisioned 集群已开启多 VPC 连接能力。详见 [通过私有链路连接接入 Amazon MSK Provisioned](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)。 + +1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，并进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 + + > **提示：** + > + > 你可以使用左上角的下拉框在组织、项目和集群之间切换。 + +2. 点击目标集群名称进入概览页面，然后在左侧导航栏点击 **Settings** > **Networking**。 + +3. 在 **Private Link Connection For Dataflow** 区域，点击 **Create Private Link Connection**。 + +4. 在 **Create Private Link Connection** 对话框中，填写以下信息： + + - **Private Link Connection Name**：输入私有链路连接的名称。 + - **Connection Type**：选择 **Amazon MSK Provisioned**。如果未显示该选项，请确保你的集群部署在 AWS 上。 + - **MSK Cluster ARN**：输入你的 Amazon MSK Provisioned 集群的 ARN，例如 `arn:aws:kafka:us-east-1:385595570414:cluster//xxxx`。 + +5. 点击 **Create**。 + ## 创建阿里云 Endpoint Service 私有链路连接 你可以通过 TiDB Cloud 控制台或 TiDB Cloud CLI 创建阿里云 Endpoint Service 私有链路连接。 @@ -100,7 +128,7 @@ ticloud serverless private-link-connection zones --cluster-id
-1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 +1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，并进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > @@ -110,7 +138,7 @@ ticloud serverless private-link-connection zones --cluster-id 3. 在 **Private Link Connection For Dataflow** 区域，点击 **Create Private Link Connection**。 -4. 在 **Create Private Link Connection** 对话框中，填写所需信息： +4. 在 **Create Private Link Connection** 对话框中，填写以下信息： - **Private Link Connection Name**：输入私有链路连接的名称。 - **Connection Type**：选择 **Alibaba Cloud Endpoint Service**。如果未显示该选项，请确保你的集群部署在阿里云上。 @@ -139,14 +167,15 @@ ticloud serverless private-link-connection zones --cluster-id ## 绑定域名到私有链路连接 -你可以将域名绑定到私有链路连接。当域名绑定到私有链路连接后，所有来自 TiDB Cloud 数据流服务到该域名的流量都将路由到此私有链路连接。当你的服务在运行时为 client 提供自定义域名（如 Kafka advertised listeners）时，这一功能非常有用。 +你可以将域名绑定到私有链路连接。当域名绑定到私有链路连接后，所有来自 TiDB Cloud 数据流服务到该域名的流量都会通过该私有链路连接路由。当你的服务在运行时为 client 提供自定义域名（如 Kafka advertised listeners）时，这一功能非常有用。 不同类型的私有链路连接支持绑定不同类型的域名。下表展示了每种私有链路连接类型支持的域名类型。 -| 私有链路连接类型 | 支持的域名类型 | -|--------------------------------|------------------------------------------------------| -| AWS Endpoint Service |
  • TiDB Cloud managed (`aws.tidbcloud.com`)
  • Confluent Dedicated (`aws.confluent.cloud`)
| -| 阿里云 Endpoint Service | TiDB Cloud managed (`alicloud.tidbcloud.com`) | +| 私有链路连接类型 | 支持的域名类型 | +|-----------------------------------|--------------------------------------------------------| +| AWS Endpoint Service |
  • TiDB Cloud managed (`aws.tidbcloud.com`)
  • Confluent Dedicated (`aws.confluent.cloud`)
| +| Alibaba Cloud Endpoint Service | TiDB Cloud managed (`alicloud.tidbcloud.com`) | +| Amazon MSK Provisioned | 不支持域名绑定。 | 如果你的域名未包含在此表中，请联系 [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) 申请支持。 @@ -157,7 +186,7 @@ ticloud serverless private-link-connection zones --cluster-id 通过 TiDB Cloud 控制台将域名绑定到私有链路连接，操作如下： -1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 +1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，并进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > @@ -171,8 +200,8 @@ ticloud serverless private-link-connection zones --cluster-id 5. 在 **Attach Domains** 对话框中，选择域名类型： - - **TiDB Cloud Managed**：域名将由 TiDB Cloud 自动生成。在生成的域名中，你可以获取该域名的唯一名称。例如，若生成的域名为 `*.use1-az1.dvs6nl5jgveztmla3pxkxgh76i.aws.plc.tidbcloud.com`，则唯一名称为 `dvs6nl5jgveztmla3pxkxgh76i`。点击 **Attach Domains** 进行确认。 - - **Confluent Cloud**：输入 Confluent Cloud Dedicated 集群提供的唯一名称以生成域名，然后点击 **Attach Domains** 进行确认。关于如何获取唯一名称，参见 [通过私有链路连接接入 Confluent Cloud](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md#step-1-set-up-a-confluent-cloud-network)。 + - **TiDB Cloud Managed**：域名将由 TiDB Cloud 自动生成。在生成的域名中，你可以获取该域名的唯一名称。例如，若生成的域名为 `*.use1-az1.dvs6nl5jgveztmla3pxkxgh76i.aws.plc.tidbcloud.com`，则唯一名称为 `dvs6nl5jgveztmla3pxkxgh76i`。点击 **Attach Domains** 确认绑定。 + - **Confluent Cloud**：输入 Confluent Cloud Dedicated 集群提供的唯一名称以生成域名，然后点击 **Attach Domains** 确认绑定。关于如何获取唯一名称，详见 [通过私有链路连接接入 Confluent Cloud](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md#step-1-set-up-a-confluent-cloud-network)。
@@ -210,7 +239,7 @@ ticloud serverless private-link-connection attach-domains -c --priv 通过 TiDB Cloud 控制台从私有链路连接解绑域名，操作如下： -1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 +1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，并进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > @@ -252,7 +281,7 @@ ticloud serverless private-link-connection attach-domains -c --priv 通过 TiDB Cloud 控制台删除私有链路连接，操作如下： -1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 +1. 登录 [TiDB Cloud 控制台](https://tidbcloud.com/)，并进入你的项目的 [**Clusters**](https://tidbcloud.com/project/clusters) 页面。 > **提示：** > @@ -281,6 +310,7 @@ ticloud serverless private-link-connection delete -c --private-link - [通过私有链路连接接入 Confluent Cloud](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md) - [通过私有链路连接接入 Amazon RDS](/tidb-cloud/serverless-private-link-connection-to-aws-rds.md) +- [通过私有链路连接接入 Amazon MSK Provisioned](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md) - [通过私有链路连接接入阿里云 ApsaraDB RDS for MySQL](/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md) - [通过私有链路连接接入 AWS 自建 Kafka](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md) - [通过私有链路连接接入阿里云自建 Kafka](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md) diff --git a/tidb-cloud/tidb-cloud-intro.md b/tidb-cloud/tidb-cloud-intro.md index e8f52564c4085..7dedacc0c7311 100644 --- a/tidb-cloud/tidb-cloud-intro.md +++ b/tidb-cloud/tidb-cloud-intro.md @@ -6,19 +6,19 @@ category: intro # 什么是 TiDB Cloud -[TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 是一款全托管的数据库即服务（DBaaS），将 [TiDB](https://docs.pingcap.com/tidb/stable/overview) —— 一个开源的 HTAP（混合事务与分析处理）数据库 —— 带到你的云端。TiDB Cloud 提供了一种简单的方式来部署和管理数据库，让你专注于应用程序开发，而无需关注数据库的复杂性。你可以在 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云上创建 TiDB Cloud 集群，快速构建关键业务应用。You can create TiDB Cloud clusters to quickly build mission-critical applications on Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. +[TiDB Cloud](https://www.pingcap.com/tidb-cloud/) 是一款完全托管的云原生数据库即服务（DBaaS），基于 [TiDB](https://docs.pingcap.com/tidb/stable/overview) —— 一个开源 HTAP (Hybrid Transactional and Analytical Processing) 数据库。TiDB Cloud 提供了一种简单的方式来部署和管理数据库，让你专注于应用程序开发，而无需关注数据库的复杂性。你可以在 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云上创建 TiDB Cloud 集群，快速构建关键业务应用。You can create TiDB Cloud clusters to quickly build mission-critical applications on Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. -![TiDB Cloud 概览](/media/tidb-cloud/tidb-cloud-overview.png) +![TiDB Cloud Overview](/media/tidb-cloud/tidb-cloud-overview.png) ## 为什么选择 TiDB Cloud -TiDB Cloud 让你几乎无需培训即可轻松处理如基础设施管理和集群部署等复杂任务。 +TiDB Cloud 让你几乎无需培训即可轻松完成如基础设施管理和集群部署等复杂任务。 -- 开发者和数据库管理员（DBA）可以轻松应对大量在线流量，并快速分析跨多个数据集的大规模数据。 +- 开发者和数据库管理员（DBA）可以轻松应对大量在线流量，并能跨多个数据集快速分析海量数据。 -- 各类规模的企业都可以轻松部署和管理 TiDB Cloud，无需预付费用，灵活应对业务增长。 +- 各类规模的企业都可以轻松部署和管理 TiDB Cloud，无需预付费用，即可适应你的业务增长。 -观看下方视频，进一步了解 TiDB Cloud： +观看以下视频，进一步了解 TiDB Cloud： @@ -26,33 +26,33 @@ TiDB Cloud 让你几乎无需培训即可轻松处理如基础设施管理和集 - **Fast and Customized Scaling** - 弹性且透明地扩展到数百个节点以应对关键负载，同时保持 ACID 事务。无需进行分片操作。你还可以根据业务需求分别扩展计算和存储节点。 + 弹性且透明地扩展到数百个节点以应对关键负载，同时保持 ACID 事务。无需担心分片（动词或动名词）。你还可以根据业务需求分别扩展计算和存储节点。 - **MySQL Compatibility** - 借助 TiDB 的 MySQL 兼容性，提高开发效率并缩短应用上线时间。可以轻松地从现有 MySQL 实例迁移数据，无需重写代码。 + 借助 TiDB 的 MySQL 兼容性，提高开发效率并缩短应用上线时间。可以轻松从现有 MySQL 实例迁移数据，无需重写代码。 - **High Availability and Reliability** - 天生高可用的架构设计。数据在多个可用区间进行复制，支持每日备份和自动故障转移，无论硬件故障、网络分区还是数据中心丢失，都能保障业务连续性。 + 天生高可用的架构设计。数据跨多个可用区复制，支持每日备份和故障自恢复，确保业务可持续性，无论是硬件故障、网络分区还是数据中心丢失。 - **Real-Time Analytics** - 内置分析引擎，实时获取分析查询结果。TiDB Cloud 能在当前数据上运行一致性的分析查询，不会影响关键业务应用。 + 内置分析引擎，实时获得分析查询结果。TiDB Cloud 可在当前数据上运行一致性的分析查询，不会影响关键业务应用。 - **Enterprise Grade Security** - 在专用网络和专用机器上保护你的数据，支持传输加密和静态加密。TiDB Cloud 已通过 SOC 2 Type 2、ISO 27001:2013、ISO 27701 认证，并完全符合 GDPR 要求。 + 在专用网络和机器上保护你的数据，支持传输加密和静态加密。TiDB Cloud 已通过 SOC 2 Type 2、ISO 27001:2013、ISO 27701 认证，并完全符合 GDPR。 - **Fully-Managed Service** - 通过易用的 Web 管理平台，仅需几次点击即可部署、扩展、监控和管理 TiDB 集群。 + 通过易用的基于 Web 的管理平台，仅需几次点击即可部署、扩展、监控和管理 TiDB 集群。 - **Multi-Cloud Support** - 保持灵活性，避免云厂商锁定。TiDB Cloud 目前支持 AWS、Azure、Google Cloud 和阿里云。 + 保持灵活性，避免被云厂商锁定。TiDB Cloud 目前支持 AWS、Azure、Google Cloud 和阿里云。 @@ -64,11 +64,11 @@ TiDB Cloud 让你几乎无需培训即可轻松处理如基础设施管理和集 - **Simple Pricing Plans** - 只为实际使用量付费，价格透明，无隐藏费用。 + 只需为实际使用付费，价格透明，无隐藏费用。 - **World-Class Support** - 通过我们的支持门户、电子邮件、聊天或视频会议，获得世界级的技术支持。 + 通过我们的支持门户、电子邮件、聊天或视频会议，获得世界级支持。 ## 部署选项 @@ -76,23 +76,23 @@ TiDB Cloud 提供以下部署选项： - TiDB Cloud Starter - TiDB Cloud Starter 是一款全托管的多租户 TiDB 服务。它提供即时、自动扩缩容的 MySQL 兼容数据库，并在超出免费额度后按用量计费。 + TiDB Cloud Starter 是一款完全托管的多租户 TiDB 产品。它提供即时、自动扩展的 MySQL 兼容数据库，并在超出免费额度后按用量计费。 - 目前，TiDB Cloud Starter 已在 AWS 上正式发布，并在阿里云上公测。 + 目前，TiDB Cloud Starter 已在 AWS 上正式上线，并在阿里云上公测。 - TiDB Cloud Essential - 针对业务负载持续增长、需要实时扩展的应用，TiDB Cloud Essential 提供灵活性和性能，助力你的业务持续发展。 + 针对需要实时扩展以应对不断增长负载的应用，TiDB Cloud Essential 提供灵活性和性能，助力你的业务增长。 目前，TiDB Cloud Essential 在 AWS 和阿里云上公测。 - 关于 TiDB Cloud Starter 与 TiDB Cloud Essential 在阿里云上的功能对比，详见 [TiDB on Alibaba Cloud](https://www.pingcap.com/partners/alibaba-cloud/)。 + 关于 TiDB Cloud Starter 与 TiDB Cloud Essential 在阿里云上的功能对比，参见 [TiDB on Alibaba Cloud](https://www.pingcap.com/partners/alibaba-cloud/)。 @@ -106,30 +106,30 @@ TiDB Cloud 提供以下部署选项： - TiDB Cloud Premium - TiDB Cloud Premium 专为对实时无限扩展有极高要求的关键业务设计，具备负载感知的自动扩缩容和全面的企业级能力。 + TiDB Cloud Premium 专为对实时无限扩展有极高要求的关键业务设计。它提供基于负载的自动扩展和全面的企业级能力。 - 目前，TiDB Cloud Premium 在 AWS 和阿里云上处于私测阶段。 + 目前，TiDB Cloud Premium 在 AWS 和阿里云上私测。 - TiDB Cloud Dedicated - TiDB Cloud Dedicated 面向关键业务，提供跨多个可用区的高可用性、横向扩展能力以及完整的 [HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing) 能力。 + TiDB Cloud Dedicated 专为关键业务打造，提供跨多个可用区的高可用、横向扩展和完整的 [HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing) 能力。 - 目前，TiDB Cloud Dedicated 已在 AWS 和 Google Cloud 上正式发布，并在 Azure 上公测。更多信息请参见 [TiDB Cloud Dedicated](https://www.pingcap.com/tidb-cloud-dedicated)。 + 目前，TiDB Cloud Dedicated 已在 AWS 和 Google Cloud 正式上线，并在 Azure 上公测。更多信息参见 [TiDB Cloud Dedicated](https://www.pingcap.com/tidb-cloud-dedicated)。 ## 架构 -![TiDB Cloud 架构](/media/tidb-cloud/tidb-cloud-architecture.png) +![TiDB Cloud architecture](/media/tidb-cloud/tidb-cloud-architecture.png) -- TiDB VPC（虚拟私有云） +- TiDB VPC (Virtual Private Cloud) 对于每个 TiDB Cloud 集群，所有 TiDB 节点及辅助节点（包括 TiDB Operator 节点和日志节点）都部署在同一个 VPC 中。 -- TiDB Cloud 中央服务 +- TiDB Cloud Central Services - 中央服务（包括计费、告警、元数据存储、Dashboard UI 等）独立部署。你可以通过互联网访问 Dashboard UI 来操作 TiDB 集群。 + 中央服务（包括计费、告警、元数据存储、Dashboard UI）独立部署。你可以通过互联网访问 Dashboard UI 来操作 TiDB 集群。 -- 你的 VPC +- Your VPC - 你可以通过私有端点连接或 VPC 对等连接接入 TiDB 集群。详细信息请参见 [Set Up Private Endpoint Connections](/tidb-cloud/set-up-private-endpoint-connections.md) 或 [Set up VPC Peering Connection](/tidb-cloud/set-up-vpc-peering-connections.md)。 \ No newline at end of file + 你可以通过私有端点连接或 VPC 对等连接访问你的 TiDB 集群。详情请参考 [Set Up Private Endpoint Connections](/tidb-cloud/set-up-private-endpoint-connections.md) 或 [Set up VPC Peering Connection](/tidb-cloud/set-up-vpc-peering-connections.md)。 \ No newline at end of file