-1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群名称进入其概览页面。
+1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群名称，进入其概览页面。
2. 点击右上角的 **Connect**，弹出连接对话框。
-3. 确保连接对话框中的配置与你的操作环境一致。
+3. 确保连接对话框中的配置与你的运行环境一致。
- **Connection Type** 设置为 `Public`
- **Branch** 设置为 `main`
- **Connect With** 设置为 `General`
- **Operating System** 与你的环境一致
- > **Tip:**
+ > **提示：**
>
> 如果你的程序运行在 Windows Subsystem for Linux (WSL) 中，请切换到对应的 Linux 发行版。
-4. 点击 **Generate Password** 生成一个随机密码。
+4. 点击 **Generate Password** 生成随机密码。
- > **Tip:**
+ > **提示：**
>
- > 如果你之前已经创建过密码，可以继续使用原密码，或者点击 **Reset Password** 生成新密码。
+ > 如果你之前已创建过密码，可以继续使用原密码，或点击 **Reset Password** 生成新密码。
5. 运行以下命令，复制 `env.sh.example` 并重命名为 `env.sh`：
@@ -101,24 +101,24 @@ cd tidb-java-hibernate-quickstart
export USE_SSL='true'
```
- 请务必将 `{}` 占位符替换为连接对话框中获取的连接参数。
+ 请务必将 `{}` 占位符替换为连接对话框中获得的连接参数。
- {{{ .starter }}} 需要安全连接，因此你需要将 `USE_SSL` 的值设置为 `true`。
+ TiDB Cloud Starter 需要安全连接，因此你需要将 `USE_SSL` 的值设置为 `true`。
7. 保存 `env.sh` 文件。
-1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群名称进入其概览页面。
+1. 进入 [**Clusters**](https://tidbcloud.com/console/clusters) 页面，然后点击目标集群名称，进入其概览页面。
2. 点击右上角的 **Connect**，弹出连接对话框。
3. 在连接对话框中，从 **Connection Type** 下拉列表选择 **Public**，然后点击 **CA cert** 下载 CA 证书。
- 如果你还没有配置 IP 访问列表，请点击 **Configure IP Access List**，或参考 [Configure an IP Access List](https://docs.pingcap.com/tidbcloud/configure-ip-access-list) 进行配置后再首次连接。
+ 如果你还未配置 IP 访问列表，请点击 **Configure IP Access List**，或参照 [配置 IP 访问列表](https://docs.pingcap.com/tidbcloud/configure-ip-access-list) 进行首次连接前的配置。
- 除了 **Public** 连接类型，TiDB Cloud Dedicated 还支持 **Private Endpoint** 和 **VPC Peering** 连接类型。更多信息请参见 [Connect to Your TiDB Cloud Dedicated Cluster](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)。
+ 除了 **Public** 连接类型，TiDB Cloud Dedicated 还支持 **Private Endpoint** 和 **VPC Peering** 连接类型。更多信息参见 [连接到你的 TiDB Cloud Dedicated 集群](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)。
4. 运行以下命令，复制 `env.sh.example` 并重命名为 `env.sh`：
@@ -137,12 +137,12 @@ cd tidb-java-hibernate-quickstart
export USE_SSL='false'
```
- 请务必将 `{}` 占位符替换为连接对话框中获取的连接参数。
+ 请务必将 `{}` 占位符替换为连接对话框中获得的连接参数。
6. 保存 `env.sh` 文件。
+
1. 运行以下命令，复制 `env.sh.example` 并重命名为 `env.sh`：
@@ -168,7 +168,7 @@ cd tidb-java-hibernate-quickstart
-### 第 3 步：运行代码并检查结果
+### 步骤 3：运行代码并检查结果
1. 执行以下命令运行示例代码：
@@ -176,13 +176,13 @@ cd tidb-java-hibernate-quickstart
make
```
-2. 检查 [Expected-Output.txt](https://github.com/tidb-samples/tidb-java-hibernate-quickstart/blob/main/Expected-Output.txt) 以确认输出是否一致。
+2. 检查 [Expected-Output.txt](https://github.com/tidb-samples/tidb-java-hibernate-quickstart/blob/main/Expected-Output.txt) 输出是否一致。
## 示例代码片段
你可以参考以下示例代码片段，完成你自己的应用开发。
-完整示例代码及运行方法请参考 [tidb-samples/tidb-java-hibernate-quickstart](https://github.com/tidb-samples/tidb-java-hibernate-quickstart) 仓库。
+完整示例代码及运行方法请参见 [tidb-samples/tidb-java-hibernate-quickstart](https://github.com/tidb-samples/tidb-java-hibernate-quickstart) 仓库。
### 连接 TiDB
@@ -198,7 +198,7 @@ cd tidb-java-hibernate-quickstart
com.mysql.cj.jdbc.Driver
-
org.hibernate.dialect.TiDBDialect
+
org.hibernate.dialect.MySQLDialect
${tidb_jdbc_url}
${tidb_user}
${tidb_password}
@@ -225,7 +225,7 @@ public SessionFactory getSessionFactory() {
}
```
-使用该函数时，需要将 `${your_entity_class}` 替换为你自己的数据实体类。如果有多个实体类，需要为每个实体类添加一条 `.addAnnotatedClass(${your_entity_class})` 语句。上述函数只是配置 Hibernate 的一种方式。如果你在配置过程中遇到问题，或想了解更多 Hibernate 相关内容，请参考 [Hibernate 官方文档](https://hibernate.org/orm/documentation)。
+使用该函数时，你需要将 `${your_entity_class}` 替换为你自己的数据实体类。对于多个实体类，需要为每个类添加一条 `.addAnnotatedClass(${your_entity_class})` 语句。上述函数只是配置 Hibernate 的一种方式。如果你在配置过程中遇到问题，或想了解更多 Hibernate 相关内容，请参考 [Hibernate 官方文档](https://hibernate.org/orm/documentation)。
### 插入或更新数据
@@ -235,7 +235,7 @@ try (Session session = sessionFactory.openSession()) {
}
```
-更多信息请参考 [插入数据](/develop/dev-guide-insert-data.md) 和 [更新数据](/develop/dev-guide-update-data.md)。
+更多信息参见 [插入数据](/develop/dev-guide-insert-data.md) 和 [修改数据](/develop/dev-guide-update-data.md)。
### 查询数据
@@ -246,7 +246,7 @@ try (Session session = sessionFactory.openSession()) {
}
```
-更多信息请参考 [查询数据](/develop/dev-guide-get-data-from-single-table.md)。
+更多信息参见 [查询数据](/develop/dev-guide-get-data-from-single-table.md)。
### 删除数据
@@ -256,12 +256,48 @@ try (Session session = sessionFactory.openSession()) {
}
```
-更多信息请参考 [删除数据](/develop/dev-guide-delete-data.md)。
+更多信息参见 [删除数据](/develop/dev-guide-delete-data.md)。
+
+## 与 `MySQLDialect` 的兼容性
+
+当你在 TiDB 中使用 `MySQLDialect` 时，请注意以下行为：
+
+### `SERIALIZABLE` 隔离级别
+
+应用程序如果尝试设置 `SERIALIZABLE` 事务隔离级别，在 TiDB 中会遇到如下错误：
+
+```
+The isolation level 'SERIALIZABLE' is not supported. Set tidb_skip_isolation_level_check=1 to skip this error
+```
+
+为避免该错误，请在服务器端设置如下 TiDB 系统变量：
+
+```sql
+SET GLOBAL tidb_skip_isolation_level_check=1;
+```
+
+启用该变量后，TiDB 会接受指定 `SERIALIZABLE` 的请求而不返回错误。内部实际仍采用 `REPEATABLE-READ`，这是 TiDB 的最强隔离级别。更多信息参见 [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check)。
+
+> **注意：**
+>
+> 社区维护的 `TiDBDialect` 会自动处理该行为，跳过需要 `SERIALIZABLE` 隔离级别的特性。
+
+### `CHECK` 约束
+
+Hibernate 的 [`@Check`](https://docs.hibernate.org/orm/6.5/javadocs/org/hibernate/annotations/Check.html) 注解会生成 DDL `CHECK` 约束。[MySQL 8.0.16 及以上版本](https://dev.mysql.com/doc/refman/8.0/en/create-table-check-constraints.html) 默认会强制执行这些约束，但 TiDB 默认不会强制执行，除非显式开启。
+
+如需在 TiDB 中启用 `CHECK` 约束强制执行，请设置如下系统变量：
+
+```sql
+SET GLOBAL tidb_enable_check_constraint=ON;
+```
+
+如果未设置该变量，TiDB 会接受 `CHECK` 约束语法但不会强制执行，可能导致数据完整性问题。更多信息参见 [`CHECK` 约束](/constraints.md#check)。
## 后续步骤
-- 通过 [Hibernate 文档](https://hibernate.org/orm/documentation) 学习更多 Hibernate 的用法。
-- 通过 [开发者指南](/develop/dev-guide-overview.md) 各章节学习 TiDB 应用开发最佳实践，例如 [插入数据](/develop/dev-guide-insert-data.md)、[更新数据](/develop/dev-guide-update-data.md)、[删除数据](/develop/dev-guide-delete-data.md)、[单表读取](/develop/dev-guide-get-data-from-single-table.md)、[事务](/develop/dev-guide-transaction-overview.md) 和 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md)。
+- 通过 [Hibernate 文档](https://hibernate.org/orm/documentation) 学习更多 Hibernate 用法。
+- 通过 [开发者指南](/develop/dev-guide-overview.md) 各章节学习 TiDB 应用开发最佳实践，例如 [插入数据](/develop/dev-guide-insert-data.md)、[修改数据](/develop/dev-guide-update-data.md)、[删除数据](/develop/dev-guide-delete-data.md)、[单表读取](/develop/dev-guide-get-data-from-single-table.md)、[事务](/develop/dev-guide-transaction-overview.md) 以及 [SQL 性能优化](/develop/dev-guide-optimize-sql-overview.md)。
- 通过专业的 [TiDB 开发者课程](https://www.pingcap.com/education/) 学习，并在通过考试后获得 [TiDB 认证](https://www.pingcap.com/education/certification/)。
- 通过 Java 开发者课程学习：[Working with TiDB from Java](https://eng.edu.pingcap.com/catalog/info/id:212)。
@@ -269,12 +305,12 @@ try (Session session = sessionFactory.openSession()) {
-在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](/support.md)。
+在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](/support.md)。
-在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或[提交支持工单](https://tidb.support.pingcap.com/)。
+在 [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc) 或 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs) 社区提问，或 [提交支持工单](https://tidb.support.pingcap.com/)。
diff --git a/latest_translation_commit.json b/latest_translation_commit.json
index bdcc3f5b1cc50..8b53f625469ed 100644
--- a/latest_translation_commit.json
+++ b/latest_translation_commit.json
@@ -1 +1,4 @@
-{"target":"release-8.5","sha":"4b35531be680642691b5fe69a8cfb8a2ef4ccae6"}
\ No newline at end of file
+{
+ "target": "release-8.5",
+ "sha": "58f3928e46f8ec9cf6e89c1ce6b5ef922f5e4054"
+}
\ No newline at end of file
diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md
index a1875606e5b00..4e6130e7cab78 100644
--- a/tidb-cloud/architecture-concepts.md
+++ b/tidb-cloud/architecture-concepts.md
@@ -7,7 +7,7 @@ summary: 了解 TiDB Cloud 的架构概念。
-TiDB Cloud 是一款全托管的数据库即服务（DBaaS），将 [TiDB](https://docs.pingcap.com/tidb/stable/overview)（一款开源 HTAP（混合事务与分析处理）数据库）的灵活性与强大功能带到 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云。
+TiDB Cloud 是一款全托管的数据库即服务（DBaaS），将 [TiDB](https://docs.pingcap.com/tidb/stable/overview) 的灵活性与强大功能带到 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure 和阿里云。TiDB 是一款开源 HTAP（混合事务与分析处理）数据库。
@@ -17,15 +17,15 @@ TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flex
-TiDB 兼容 MySQL，使得迁移和对接现有应用变得简单，同时提供无缝扩展能力，能够从小型负载到大规模高性能集群轻松应对。它在同一系统中同时支持事务型（OLTP）和分析型（OLAP）负载，简化运维并实现实时洞察。
+TiDB 兼容 MySQL，使得迁移和对接现有应用变得简单，同时具备无缝扩展性，能够应对从小型负载到大规模高性能集群的各种需求。它在一个系统中同时支持事务型（OLTP）和分析型（OLAP）负载，简化运维并实现实时洞察。
TiDB Cloud 让你轻松扩展数据库，处理复杂的管理任务，专注于开发可靠且高性能的应用。
-- 对于 AWS，TiDB Cloud 提供 **TiDB Cloud Starter**，适用于自动扩缩、成本高效的负载，**TiDB Cloud Essential**，适用于具备预配置容量的生产级负载，以及 **TiDB Cloud Dedicated**，适用于企业级应用，拥有专属资源和高级能力。
-- 对于 Google Cloud 和 Azure，TiDB Cloud 提供 **TiDB Cloud Dedicated**，适用于企业级应用，拥有专属资源和高级能力。
-- 对于阿里云，TiDB Cloud 提供 **TiDB Cloud Starter**，适用于自动扩缩、成本高效的负载，以及 **TiDB Cloud Essential**，适用于具备预配置容量的生产级负载。
+- 对于 AWS，TiDB Cloud 提供 **TiDB Cloud Starter**，适用于自动扩展、成本高效的负载；**TiDB Cloud Essential**，适用于具备预配置容量的生产级负载；以及 **TiDB Cloud Dedicated**，适用于企业级应用，具备专属资源和高级功能。
+- 对于 Google Cloud 和 Azure，TiDB Cloud 提供 **TiDB Cloud Dedicated**，适用于企业级应用，具备专属资源和高级功能。
+- 对于阿里云，TiDB Cloud 提供 **TiDB Cloud Starter**，适用于自动扩展、成本高效的负载，以及 **TiDB Cloud Essential**，适用于具备预配置容量的生产级负载。
@@ -38,35 +38,35 @@ TiDB Cloud 让你轻松扩展数据库，处理复杂的管理任务，专注于
## TiDB Cloud Starter
-TiDB Cloud Starter 是一款全托管的多租户 TiDB 服务，提供即开即用、自动扩缩的 MySQL 兼容数据库。
+TiDB Cloud Starter 是一款全托管的多租户 TiDB 产品，提供即开即用、自动扩展的 MySQL 兼容数据库。
Starter 集群方案非常适合刚开始使用 TiDB Cloud 的用户。它为开发者和小型团队提供以下特性：
- **免费**：该方案完全免费，无需信用卡即可开始使用。
- **存储**：提供初始 5 GiB 的行存储和 5 GiB 的列存储。
-- **请求单元**：包含 5000 万 [请求单元（RUs）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) 用于数据库操作。
+- **Request Units**：包含 5000 万 [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) 用于数据库操作。
## TiDB Cloud Essential
-对于负载持续增长、需要实时扩展的应用，Essential 集群方案提供灵活性和性能，助力你的业务增长，具备以下特性：
+对于负载持续增长、需要实时扩展性的应用，Essential 集群方案提供灵活性和性能，助力你的业务增长，具备以下特性：
-- **增强能力**：包含 Starter 方案的全部能力，并具备处理更大、更复杂负载的能力，以及高级安全特性。
-- **自动扩缩**：自动调整存储和计算资源，高效应对不断变化的负载需求。
-- **高可用性**：内置容错和冗余机制，确保你的应用即使在基础设施故障时也能保持可用和弹性。
-- **可预测的定价**：根据存储和计算资源的请求容量单元（RCUs）计费，提供透明、按用量计费的定价模式，随需扩展，让你只为实际使用的资源付费，无额外意外支出。
+- **增强功能**：包含 Starter 方案的全部功能，并具备处理更大、更复杂负载的能力，以及高级安全特性。
+- **自动扩展**：自动调整存储和计算资源，高效应对不断变化的负载需求。
+- **高可用性**：内置容错和冗余机制，确保你的应用在基础设施故障时依然可用且具备弹性。
+- **可预测的定价**：根据存储和计算资源的 Request Capacity Units (RCUs) 计费，提供透明、按用量计费的定价模式，随需扩展，按实际使用付费，无隐藏费用。
TiDB Cloud Essential 提供两种高可用性选项，以满足不同的运维需求。
-- 默认情况下，采用区域可用性（Zonal High Availability）选项的集群，其所有组件都位于同一可用区，带来更低的网络延迟。
-- 对于需要最大基础设施隔离和冗余的应用，可以选择区域级高可用性（Regional High Availability）选项，将节点分布在多个可用区。
+- 默认情况下，采用 Zonal High Availability 选项的集群，其所有组件都位于同一可用区，从而降低网络延时。
+- 对于需要最大基础设施隔离和冗余的应用，Regional High Availability 选项会将节点分布在多个可用区。
-更多信息，参见 [TiDB Cloud Starter 和 Essential 的高可用性](/tidb-cloud/serverless-high-availability.md)。
+更多信息，参见 [TiDB Cloud 的高可用性](/tidb-cloud/serverless-high-availability.md)。
## TiDB Cloud Dedicated
-TiDB Cloud Dedicated 专为关键业务设计，提供跨多个可用区的高可用性、水平扩展能力和完整的 HTAP 能力。
+TiDB Cloud Dedicated 专为关键业务设计，提供跨多个可用区的高可用性、水平扩展能力以及完整的 HTAP 能力。
-该方案基于隔离的云资源（如 VPC、VM、托管 Kubernetes 服务和云存储）构建，充分利用主流云服务商的基础设施。TiDB Cloud Dedicated 集群支持完整的 TiDB 功能集，实现快速扩展、可靠备份、在指定 VPC 内部署以及地理级别的灾备能力。
+该方案基于隔离的云资源（如 VPC、VM、托管 Kubernetes 服务和云存储）构建，充分利用主流云服务商的基础设施。TiDB Cloud Dedicated 集群支持完整的 TiDB 功能集，实现快速扩展、可靠备份、在指定 VPC 内部署以及地域级容灾。
@@ -94,18 +94,18 @@ TiDB Cloud API 是基于 REST 的接口，提供对 TiDB Cloud Starter 和 TiDB
在 TiDB Cloud 中，每个集群由 TiDB、TiKV 和 TiFlash 节点组成。
-- 在 TiDB Cloud Dedicated 集群中，你可以根据性能需求完全管理专属 TiDB、TiKV 和 TiFlash 节点的数量和规格。更多信息，参见 [可扩展性](/tidb-cloud/scalability-concepts.md)。
-- 在 TiDB Cloud Starter 或 TiDB Cloud Essential 集群中，TiDB、TiKV 和 TiFlash 节点的数量和规格由系统自动管理。这确保了无缝扩展，无需用户手动配置或管理节点。
+- 在 TiDB Cloud Dedicated 集群中，你可以根据性能需求完全管理专属 TiDB、TiKV 和 TiFlash 节点的数量和规格。更多信息，参见 [扩展性](/tidb-cloud/scalability-concepts.md)。
+- 在 TiDB Cloud Starter 或 TiDB Cloud Essential 集群中，TiDB、TiKV 和 TiFlash 节点的数量和规格由系统自动管理，确保无缝扩展，无需用户手动配置或管理节点。
### TiDB 节点
-[TiDB 节点](/tidb-computing.md) 是无状态的 SQL 层，通过 MySQL 兼容的端点与应用连接。它负责解析、优化 SQL 查询，并生成分布式执行计划。
+[TiDB 节点](/tidb-computing.md) 是无状态的 SQL 层，通过 MySQL 兼容端点与应用连接。它负责解析、优化 SQL 查询，并生成分布式执行计划。
-你可以部署多个 TiDB 节点以实现水平扩展，处理更高的负载。这些节点通常与负载均衡器（如 TiProxy 或 HAProxy）配合使用，提供无缝接口。TiDB 节点本身不存储数据——它们会将数据请求转发给 TiKV 节点（用于行存储）或 TiFlash 节点（用于列存储）。
+你可以部署多个 TiDB 节点以实现水平扩展，处理更高负载。这些节点与负载均衡器（如 TiProxy 或 HAProxy）协同工作，提供无缝接口。TiDB 节点本身不存储数据——它们会将数据请求转发给 TiKV 节点（行存储）或 TiFlash 节点（列存储）。
### TiKV 节点
-[TiKV 节点](/tikv-overview.md) 是 TiDB 架构中数据存储的核心，作为分布式事务型键值存储引擎，具备高可靠性、可扩展性和高可用性。
+[TiKV 节点](/tikv-overview.md) 是 TiDB 架构中数据存储的核心，作为分布式事务型键值存储引擎，具备可靠性、扩展性和高可用性。
**主要特性：**
@@ -116,27 +116,27 @@ TiDB Cloud API 是基于 REST 的接口，提供对 TiDB Cloud Starter 和 TiDB
- **事务支持**
- - TiKV 节点在键值层面原生支持分布式事务，默认隔离级别为快照隔离（Snapshot Isolation）。
- - TiDB 节点将 SQL 执行计划转化为对 TiKV 节点 API 的调用，实现无缝的 SQL 级事务支持。
+ - TiKV 节点在键值层面原生支持分布式事务，默认隔离级别为 Snapshot Isolation。
+ - TiDB 节点将 SQL 执行计划转换为对 TiKV 节点 API 的调用，实现无缝的 SQL 级事务支持。
- **高可用性**
- - TiKV 节点中的所有数据都会被复制（默认：三副本），以保证数据持久性。
- - TiKV 原生支持高可用和自动故障转移，防止节点故障带来的影响。
+ - TiKV 节点中的所有数据都会被复制（默认 3 副本），以保证持久性。
+ - TiKV 原生支持高可用性和自动故障转移，防止节点故障带来的影响。
-- **可扩展性与可靠性**
+- **扩展性与可靠性**
- TiKV 节点设计用于处理不断扩展的数据集，同时保持分布式一致性和容错能力。
### TiFlash 节点
-[TiFlash 节点](/tiflash/tiflash-overview.md) 是 TiDB 架构中的一种专用存储节点。与普通 TiKV 节点不同，TiFlash 采用列式存储模型，专为分析加速设计。
+[TiFlash 节点](/tiflash/tiflash-overview.md) 是 TiDB 架构中的一种专用存储节点。与普通 TiKV 节点不同，TiFlash 采用列存储模型，专为分析加速设计。
**主要特性：**
-- **列式存储**
+- **列存储**
- TiFlash 节点以列存格式存储数据，针对分析型查询进行了优化，显著提升了读密集型负载的性能。
+ TiFlash 节点以列式格式存储数据，针对分析型查询进行了优化，显著提升了读密集型负载的性能。
- **向量检索索引支持**
diff --git a/tidb-cloud/key-concepts.md b/tidb-cloud/key-concepts.md
index bf5adda77d7f1..a225eb1248f1e 100644
--- a/tidb-cloud/key-concepts.md
+++ b/tidb-cloud/key-concepts.md
@@ -9,51 +9,51 @@ summary: 了解 TiDB Cloud 的关键概念。
## 架构
-TiDB Cloud 基于云原生分布式架构构建，实现了计算与存储分离，支持弹性扩展和高可用性。[了解更多 TiDB Cloud 架构相关内容](/tidb-cloud/architecture-concepts.md)。
+TiDB Cloud 基于云原生分布式架构构建，实现了计算与存储分离，支持弹性扩展和高可用。[了解更多 TiDB Cloud 架构](/tidb-cloud/architecture-concepts.md)。
-## 数据库模式
+## 数据库 schema
-TiDB Cloud 允许你通过数据库、数据表、列、索引和约束等对象来组织和结构化你的数据。同时还支持临时表、向量索引和缓存表等高级特性。[了解更多数据库模式相关内容](/tidb-cloud/database-schema-concepts.md)。
+TiDB Cloud 允许你通过数据库、表、列、索引和约束等对象来组织和结构化你的数据。同时还支持临时表、向量索引和缓存表等高级功能。[了解更多数据库 schema](/tidb-cloud/database-schema-concepts.md)。
## 事务
-TiDB 提供完整的分布式事务，并在 [Google Percolator](https://research.google.com/pubs/pub36726.html) 的基础上进行了部分优化。[了解更多事务相关内容](/tidb-cloud/transaction-concepts.md)。
+TiDB 提供完整的分布式事务，并在 [Google Percolator](https://research.google.com/pubs/pub36726.html) 的基础上进行了部分优化。[了解更多事务](/tidb-cloud/transaction-concepts.md)。
## SQL
-TiDB 高度兼容 MySQL 协议，以及 MySQL 5.7 和 MySQL 8.0 的常用特性和语法。[了解更多 TiDB Cloud 中的 SQL 相关内容](/tidb-cloud/sql-concepts.md)。
+TiDB 高度兼容 MySQL 协议，以及 MySQL 5.7 和 MySQL 8.0 的常用功能和语法。[了解更多 TiDB Cloud 中的 SQL](/tidb-cloud/sql-concepts.md)。
-## AI 特性
+## AI 功能
-TiDB Cloud 的 AI 特性使你能够充分利用先进技术进行数据探索、检索和集成。[了解更多 AI 特性相关内容](/tidb-cloud/ai-feature-concepts.md)。
+TiDB Cloud 的 AI 功能使你能够充分利用先进技术进行数据探索、搜索和集成。[了解更多 AI 功能](/tidb-cloud/ai-feature-concepts.md)。
-## 数据服务（Beta）
+## Data Service（Beta）
-数据服务允许你通过自定义 API 端点，以 HTTPS 请求方式访问 TiDB Cloud 数据。[了解更多数据服务相关内容](/tidb-cloud/data-service-concepts.md)。
+Data Service 允许你通过自定义 API 端点，使用 HTTPS 请求访问 TiDB Cloud 数据。[了解更多 Data Service](/tidb-cloud/data-service-concepts.md)。
-## 可扩展性
+## 扩展性
-TiDB Cloud Dedicated 允许你分别调整计算和存储资源，以适应数据量或工作负载的变化。[了解更多可扩展性相关内容](/tidb-cloud/scalability-concepts.md)。
+TiDB Cloud Dedicated 支持你分别调整计算和存储资源，以适应数据量或负载的变化。[了解更多扩展性](/tidb-cloud/scalability-concepts.md)。
-## 高可用性
+## 高可用
-TiDB Cloud 在 TiDB Cloud Serverless 和 TiDB Cloud Dedicated 集群中都能确保高可用性：
+TiDB Cloud 在所有支持的方案中都保证高可用：
-- [TiDB Cloud Serverless 的高可用性](/tidb-cloud/serverless-high-availability.md)
-- [TiDB Cloud Dedicated 的高可用性](/tidb-cloud/high-availability-with-multi-az.md)
+- 对于
TiDB Cloud Starter 和 TiDB Cloud Essential TiDB Cloud Starter、TiDB Cloud Essential 和 TiDB Cloud Premium，参见 [TiDB Cloud 的高可用](/tidb-cloud/serverless-high-availability.md)。
+- 对于 TiDB Cloud Dedicated，参见 [TiDB Cloud Dedicated 的高可用](/tidb-cloud/high-availability-with-multi-az.md)。
## 监控
-TiDB Cloud 提供了全面的集群性能和健康状况监控能力。[了解更多监控相关内容](/tidb-cloud/monitoring-concepts.md)。
+TiDB Cloud 提供全面的集群性能与健康监控能力。[了解更多监控](/tidb-cloud/monitoring-concepts.md)。
## 数据流
-TiDB Cloud 允许你将 TiDB 集群中的数据变更流式传输到其他系统，如 Kafka、MySQL 和对象存储。[了解更多数据流相关内容](/tidb-cloud/data-streaming-concepts.md)。
+TiDB Cloud 支持将 TiDB 集群中的数据变更流式传输到其他系统，如 Kafka、MySQL 和对象存储。[了解更多数据流](/tidb-cloud/data-streaming-concepts.md)。
## 备份与恢复
-TiDB Cloud 提供自动化备份方案和时间点恢复（PITR）能力。[了解更多备份与恢复相关内容](/tidb-cloud/backup-and-restore-concepts.md)。
+TiDB Cloud 提供自动化备份方案和时间点恢复（PITR）能力。[了解更多备份与恢复](/tidb-cloud/backup-and-restore-concepts.md)。
## 安全
-TiDB Cloud 提供强大且灵活的安全框架，旨在保护数据、实施访问控制，并满足现代合规标准。[了解更多安全相关内容](/tidb-cloud/security-concepts.md)。
\ No newline at end of file
+TiDB Cloud 提供强大且灵活的安全框架，旨在保护数据、实施访问控制，并满足现代合规标准。[了解更多安全](/tidb-cloud/security-concepts.md)。
\ No newline at end of file
diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md
index f3580bc3f1fbe..a05e4f8a1c38a 100644
--- a/tidb-cloud/serverless-high-availability.md
+++ b/tidb-cloud/serverless-high-availability.md
@@ -1,38 +1,57 @@
---
-title: TiDB Cloud Starter 和 Essential 的高可用性
-summary: 了解 TiDB Cloud Starter 和 Essential 的高可用性架构。探索可用区级和区域级高可用性选项、自动备份、故障转移流程，以及 TiDB 如何确保数据持久性和业务连续性。
+title: TiDB Cloud 高可用
+summary: 了解 TiDB Cloud 的高可用架构。探索分区高可用与区域高可用选项、自动备份、故障转移流程，以及 TiDB 如何确保数据持久性和业务可持续性。
---
-# TiDB Cloud Starter 和 Essential 的高可用性
+# TiDB Cloud 高可用
-TiDB Cloud 通过强大的机制默认实现高可用性和数据持久性，防止单点故障，并确保即使在发生中断时也能持续提供服务。作为基于经过实战考验的 TiDB 开源产品的全托管服务，TiDB Cloud 继承了 TiDB 的核心高可用（HA）特性，并结合了额外的云原生能力。
+TiDB Cloud 通过强大的机制，默认保障高可用和数据持久性，防止单点故障，并确保即使在发生中断时也能持续提供 service。作为基于经过实战检验的 TiDB 开源产品的全托管 service，TiDB Cloud 继承了 TiDB 的核心高可用（HA）特性，并结合了额外的云原生能力。
+
+> **注意：**
+>
+> - 本文档仅适用于
TiDB Cloud Starter 和 TiDB Cloud EssentialTiDB Cloud Starter、TiDB Cloud Essential 和 TiDB Cloud Premium。
+> - 关于 TiDB Cloud Dedicated 的高可用，请参见 [TiDB Cloud Dedicated 高可用](/tidb-cloud/high-availability-with-multi-az.md)。
## 概述
-TiDB 通过 Raft 一致性算法实现高可用性和数据持久性。该算法能够在多个节点间一致地复制数据变更，使 TiDB 即使在节点故障或网络分区的情况下也能处理读写请求。这种方式同时提供了高数据持久性和容错能力。
+TiDB 通过 Raft 一致性算法保障高可用和数据持久性。该算法会持续地在多个 node 之间复制数据修改，使 TiDB 即使在 node 故障或网络分区时也能处理读写 request。这种方式同时提供了高数据持久性和容错能力。
+
+TiDB Cloud 在此基础上，扩展了分区高可用和区域高可用能力，以满足不同的运维需求。
-TiDB Cloud 通过可用区级高可用性和区域级高可用性扩展了这些能力，以满足不同的运维需求。
+
> **注意：**
>
-> - 对于 TiDB Cloud Starter 集群，仅启用可用区级高可用性，且不可配置。
-> - 对于部署在 AWS 东京（ap-northeast-1）区域或任意阿里云区域的 TiDB Cloud Essential 集群，默认启用区域级高可用性。你可以在集群创建时根据需要切换为可用区级高可用性。对于部署在其他区域的 TiDB Cloud Essential 集群，仅启用可用区级高可用性，且不可配置。
+> - 对于 TiDB Cloud Starter cluster，仅启用分区高可用，且不可配置。
+> - 对于部署在 AWS 东京（ap-northeast-1）Region 或任意阿里云 Region 的 TiDB Cloud Essential cluster，默认启用区域高可用。你可以在创建 cluster 时根据需要切换为分区高可用。对于部署在其他 Region 的 TiDB Cloud Essential cluster，仅启用分区高可用，且不可配置。
-- **可用区级高可用性**：该选项将所有节点部署在同一个可用区内，从而降低网络延迟。它无需应用层跨区冗余即可实现高可用性，适用于优先考虑单区低延迟的应用。详细信息参见 [可用区级高可用性架构](#zonal-high-availability-architecture)。
+
-- **区域级高可用性（测试版）**：该选项将节点分布在多个可用区，实现最大程度的基础设施隔离和冗余。它提供最高级别的可用性，但需要应用层实现跨区冗余。如果你需要最大程度防护可用区级基础设施故障，建议选择该选项。需要注意的是，该选项会增加延迟，并可能产生跨区数据传输费用。此功能仅在拥有三个以上可用区的区域可用，且只能在集群创建时启用。详细信息参见 [区域级高可用性架构](#regional-high-availability-architecture)。
+
-## 可用区级高可用性架构
+> **注意：**
+>
+> - 对于 TiDB Cloud Starter cluster，仅启用分区高可用，且不可配置。
+> - 对于 TiDB Cloud Premium cluster，仅启用区域高可用，且不可配置。
+> - 对于部署在 AWS 东京（ap-northeast-1）Region 或任意阿里云 Region 的 TiDB Cloud Essential cluster，默认启用区域高可用。你可以在创建 cluster 时根据需要切换为分区高可用。对于部署在其他 Region 的 TiDB Cloud Essential cluster，仅启用分区高可用，且不可配置。
-当你以默认的可用区级高可用性创建集群时，所有组件，包括 Gateway、TiDB、TiKV 和 TiFlash 计算/写入节点，均运行在同一个可用区内。这些组件在数据平面上的部署通过虚拟机池实现基础设施冗余，从而最大程度减少故障转移时间和由于同区部署带来的网络延迟。
+
+
+- **分区高可用**：该选项将所有 node 部署在同一可用区内，降低网络延时。它无需在应用层实现跨区冗余即可保障高可用，适用于对单区低延时有较高要求的应用。详细信息参见 [分区高可用架构](#zonal-high-availability-architecture)。
+
+- **区域高可用（beta）**：该选项将 node 分布在多个可用区，实现最大程度的基础设施隔离和冗余。它提供最高级别的可用性，但需要应用层实现跨区冗余。如果你需要最大程度防护单区基础设施故障，建议选择该选项。需要注意的是，该模式会增加延时，并可能产生跨区数据传输费用。该功能仅在拥有三个及以上可用区的 Region 可用，且只能在 cluster 创建时启用。详细信息参见 [区域高可用架构](#regional-high-availability-architecture)。
+
+## 分区高可用架构
+
+当你以默认分区高可用创建 cluster 时，所有组件（包括 Gateway、TiDB、TiKV 和 TiFlash 计算/写 node）均运行在同一可用区内。数据面组件的部署通过虚拟机池提供基础设施冗余，从而最大程度减少故障转移时间和因同区部署带来的网络延时。
-- 下图展示了 AWS 上的可用区级高可用性架构：
+- 下图展示了 AWS 上分区高可用的架构：
-- 下图展示了阿里云上的可用区级高可用性架构：
+- 下图展示了阿里云上分区高可用的架构：
@@ -40,59 +59,59 @@ TiDB Cloud 通过可用区级高可用性和区域级高可用性扩展了这些
-The following diagram shows the architecture of zonal high availability on AWS:
+下图展示了 AWS 上分区高可用的架构：
-在可用区级高可用性架构中：
+在分区高可用架构下：
-- Placement Driver（PD）跨多个可用区部署，通过跨区冗余复制数据以确保高可用性。
-- 数据在本地可用区内的 TiKV 服务器和 TiFlash 写入节点之间进行复制。
-- TiDB 服务器和 TiFlash 计算节点从 TiKV 和 TiFlash 写入节点进行读写，这些节点通过存储级别的复制机制得到保护。
+- Placement Driver（PD）跨多个可用区部署，通过跨区冗余复制数据保障高可用。
+- 数据在本地可用区内的 TiKV server 和 TiFlash 写 node 之间复制。
+- TiDB server 和 TiFlash 计算 node 负责从 TiKV 和 TiFlash 写 node 读写数据，这些 node 通过存储层复制机制保障数据安全。
### 故障转移流程
-TiDB Cloud 为你的应用确保透明的故障转移流程。在故障转移期间：
+TiDB Cloud 为你的应用保障透明的故障转移流程。在故障转移期间：
-- 会创建一个新的副本来替换故障副本。
+- 会创建新的副本以替换故障副本。
-- 提供存储服务的服务器会从 Amazon S3 或阿里云 OSS（取决于你的云服务商）持久化的数据中恢复本地缓存，将系统恢复到与副本一致的状态。
+- 提供存储 service 的 server 会从 Amazon S3 或阿里云 OSS（取决于你的云服务商）持久化数据中恢复本地 cache，将系统恢复到与副本一致的状态。
-在存储层，持久化数据会定期推送到 Amazon S3 或阿里云 OSS（取决于你的云服务商），以实现高持久性。此外，最新的数据变更不仅会在多个 TiKV 服务器间复制，还会存储在每台服务器的 EBS 上，EBS 进一步复制数据以增强持久性。TiDB 会自动在毫秒级别进行退避和重试，从而确保故障转移过程对客户端应用无缝。
+在存储层，持久化数据会定期 push 到 Amazon S3 或阿里云 OSS（取决于你的云服务商），以实现高持久性。此外，实时 update 不仅会在多个 TiKV server 之间复制，还会存储在每台 server 的 EBS 上，EBS 也会进一步复制数据以增强持久性。TiDB 会自动在毫秒级别进行退避和重试，确保故障转移过程对 client 应用无感。
-- A new replica is created to replace the failed one.
+- 会创建新的副本以替换故障副本。
-- Servers providing storage services recover local caches from persisted data on Amazon S3 (depending on your cloud provider), restoring the system to a consistent state with the replicas.
+- 提供存储 service 的 server 会从 Amazon S3（取决于你的云服务商）持久化数据中恢复本地 cache，将系统恢复到与副本一致的状态。
-In the storage layer, persisted data is regularly pushed to Amazon S3 for high durability. Moreover, immediate updates are not only replicated across multiple TiKV servers but also stored on the EBS of each server, which further replicates the data for additional durability. TiDB automatically resolves issues by backing off and retrying in milliseconds, ensuring the failover process remains seamless for client applications.
+在存储层，持久化数据会定期 push 到 Amazon S3，以实现高持久性。此外，实时 update 不仅会在多个 TiKV server 之间复制，还会存储在每台 server 的 EBS 上，EBS 也会进一步复制数据以增强持久性。TiDB 会自动在毫秒级别进行退避和重试，确保故障转移过程对 client 应用无感。
-Gateway 和计算层为无状态组件，因此故障转移时会立即在其他位置重启。应用应实现连接重试逻辑。虽然可用区级架构提供了高可用性，但无法应对整个可用区的故障。如果可用区不可用，将会发生停机，直到该区及其依赖服务恢复。
+Gateway 和计算层为无状态的，因此故障转移时会立即在其他位置重启。应用应实现连接的重试 logic。分区高可用虽然能提供高可用，但无法应对整个可用区故障。如果可用区不可用，将会发生停机，直到该区及其依赖的 service 恢复。
-## 区域级高可用性架构
+## 区域高可用架构
-当你以区域级高可用性创建集群时，关键的 OLTP（联机事务处理）工作负载组件，如 PD 和 TiKV，会跨多个可用区部署，以确保冗余复制并最大化可用性。在正常运行期间，Gateway、TiDB 和 TiFlash 计算/写入节点等组件会部署在主可用区。这些数据平面组件通过虚拟机池实现基础设施冗余，从而最大程度减少故障转移时间和由于同区部署带来的网络延迟。
+当你以区域高可用创建 cluster 时，关键 OLTP（联机事务处理）负载组件（如 PD 和 TiKV）会跨多个可用区部署，以实现冗余复制并最大化可用性。正常运行时，Gateway、TiDB 和 TiFlash 计算/写 node 等组件部署在主可用区。数据面组件通过虚拟机池提供基础设施冗余，从而最大程度减少故障转移时间和因同区部署带来的网络延时。
> **注意：**
>
-> 区域级高可用性目前为测试版。
+> 区域高可用目前为 beta 版本。
-- 下图展示了 AWS 上的区域级高可用性架构：
+- 下图展示了 AWS 上区域高可用的架构：
-- 下图展示了阿里云上的区域级高可用性架构：
+- 下图展示了阿里云上区域高可用的架构：
@@ -100,77 +119,77 @@ Gateway 和计算层为无状态组件，因此故障转移时会立即在其他
-The following diagram shows the architecture of regional high availability on AWS:
+下图展示了 AWS 上区域高可用的架构：
-在区域级高可用性架构中：
+在区域高可用架构下：
-- Placement Driver（PD）和 TiKV 跨多个可用区部署，数据始终在各区间冗余复制，以确保最高级别的可用性。
-- 数据在主可用区内的 TiFlash 写入节点之间进行复制。
-- TiDB 服务器和 TiFlash 计算节点从这些 TiKV 和 TiFlash 写入节点进行读写，这些节点通过存储级别的复制机制得到保护。
+- Placement Driver（PD）和 TiKV 跨多个可用区部署，数据始终在各区冗余复制，以确保最高级别的可用性。
+- 数据在主可用区内的 TiFlash 写 node 之间复制。
+- TiDB server 和 TiFlash 计算 node 负责从这些 TiKV 和 TiFlash 写 node 读写数据，这些 node 通过存储层复制机制保障数据安全。
### 故障转移流程
-在极少数情况下，主可用区发生故障（如自然灾害、配置变更、软件问题或硬件故障），关键的 OLTP 工作负载组件（包括 Gateway 和 TiDB）会自动在备用可用区启动。流量会自动重定向到备用区，以确保快速恢复并保持业务连续性。
+在极少数主可用区故障的场景下（可能由自然灾害、配置变更、软件问题或硬件故障引起），关键 OLTP 负载组件（包括 Gateway 和 TiDB）会自动在备用可用区启动。流量会自动切换到备用区，以确保快速恢复并保障业务可持续性。
-TiDB Cloud 通过以下措施最大程度减少主可用区故障期间的服务中断，并确保业务连续性：
+TiDB Cloud 通过以下措施，最大程度减少主可用区故障时的 service 中断，并保障业务可持续性：
-- 在备用可用区自动创建 Gateway 和 TiDB 的新副本。
+- 自动在备用可用区创建新的 Gateway 和 TiDB 副本。
- 通过弹性负载均衡器检测备用可用区的活跃 Gateway 副本，并将 OLTP 流量从故障主区重定向到备用区。
-除了通过 TiKV 复制实现高可用性外，TiKV 实例还会部署并配置为将每个数据副本放置在不同的可用区。只要有两个可用区正常运行，系统就能保持可用性。为实现高持久性，数据会定期备份到 S3。即使两个可用区同时故障，存储在 S3 上的数据依然可访问和恢复。
+除了通过 TiKV 复制提供高可用外，TiKV 实例还会部署并配置为将每个数据副本放置在不同的可用区。只要有两个可用区正常运行，系统就能保持可用。为实现高持久性，数据会定期备份到 S3。即使两个可用区同时故障，存储在 S3 的数据依然可访问和恢复。
-应用不会受到非主可用区故障的影响，也不会感知到此类事件。在主可用区故障期间，Gateway 和 TiDB 会在备用可用区启动以处理工作负载。请确保你的应用实现重试逻辑，将新请求重定向到备用可用区的活跃服务器。
+应用不会受到非主可用区故障的影响，也不会感知到此类事件。在主可用区故障时，Gateway 和 TiDB 会在备用可用区启动以处理负载。请确保你的应用实现重试 logic，将新 request 重定向到备用可用区的活跃 server。
## 自动备份与持久性
-数据库备份对于业务连续性和灾难恢复至关重要，有助于防止数据损坏或意外删除。通过备份，你可以在保留期内将数据库恢复到某一时间点，最大程度减少数据丢失和停机时间。
+数据库备份对于业务可持续性和容灾至关重要，有助于防止数据损坏或误删。通过备份，你可以在保留时间内将数据库恢复到任意时间点，最大程度减少数据丢失和停机时间。
-TiDB Cloud 提供了强大的自动化备份机制，确保持续的数据保护：
+TiDB Cloud 提供强大的自动备份机制，持续保护你的数据：
-- **每日全量备份**：每天对数据库进行一次全量备份，捕获整个数据库的状态。
-- **持续事务日志备份**：事务日志会持续备份，大约每 5 分钟一次，具体频率取决于数据库活动量。
+- **每日全量备份**：每天对数据库进行一次全量备份，捕获数据库的完整状态。
+- **持续事务日志备份**：事务日志会持续备份，约每 5 分钟一次，具体频率取决于数据库活动量。
-这些自动化备份使你可以通过全量备份或结合全量备份与持续事务日志，将数据库恢复到某一特定时间点。这种灵活性确保你能够将数据库恢复到事故发生前的精确时间点。
+这些自动备份机制支持你通过全量备份或结合全量备份与持续事务日志，将数据库恢复到任意时间点。这种灵活性确保你可以将数据库恢复到事故发生前的精确时刻。
> **注意：**
>
-> 自动备份（包括基于快照的备份和用于时间点恢复（PITR）的持续备份）会在 Amazon S3 或阿里云 OSS（取决于你的云服务商）上执行，具备区域级高持久性。
+> 自动备份（包括基于快照的备份和用于时间点恢复（PITR）的持续备份）会存储在 Amazon S3 或阿里云 OSS（取决于你的云服务商），具备区域级高持久性。
-> **Note:**
+> **注意：**
>
-> Automatic backups, including snapshot-based and continuous backups for Point-in-Time Recovery (PITR), are performed on Amazon S3, which provides regional-level high durability.
+> 自动备份（包括基于快照的备份和用于时间点恢复（PITR）的持续备份）会存储在 Amazon S3，具备区域级高持久性。
## 故障期间对会话的影响
-在发生故障时，故障服务器上的进行中事务可能会被中断。虽然故障转移对应用是透明的，但你必须实现逻辑以处理活动事务中的可恢复故障。不同故障场景的处理方式如下：
+在故障期间，正在故障 server 上运行的事务可能会被中断。虽然故障转移对应用是透明的，但你必须实现相应 logic 以处理活跃事务中的可恢复故障。不同故障场景的处理方式如下：
-- **TiDB 故障**：如果某个 TiDB 实例故障，客户端连接不会受到影响，因为 TiDB Cloud 会自动通过 Gateway 重路由流量。虽然故障 TiDB 实例上的事务可能会被中断，但系统会确保已提交的数据被保留，新事务会由其他可用的 TiDB 实例处理。
-- **Gateway 故障**：如果 Gateway 故障，客户端连接会被中断。但 TiDB Cloud 的 Gateway 是无状态的，可以立即在新的可用区或服务器上重启。流量会自动重定向到新的 Gateway，最大程度减少停机时间。
+- **TiDB 故障**：如果 TiDB 实例故障，client 连接不会受影响，因为 TiDB Cloud 会自动通过 Gateway 重定向流量。虽然故障 TiDB 实例上的事务可能会中断，但系统会确保已提交数据被保留，新事务会由其他可用 TiDB 实例处理。
+- **Gateway 故障**：如果 Gateway 故障，client 连接会被中断。但 TiDB Cloud 的 Gateway 为无状态的，可以立即在新可用区或 server 上重启。流量会自动重定向到新的 Gateway，最大程度减少停机时间。
-建议你的应用实现重试逻辑以处理可恢复故障。具体实现细节请参考你的驱动或 ORM 文档（例如 [JDBC](https://dev.mysql.com/doc/connector-j/en/connector-j-config-failover.html)）。
+建议你在应用中实现重试 logic，以处理可恢复故障。具体实现方式请参考你的驱动或 ORM 文档（例如 [JDBC](https://dev.mysql.com/doc/connector-j/en/connector-j-config-failover.html)）。
## RTO 和 RPO
-在制定业务连续性计划时，请考虑以下两个关键指标：
+在制定业务可持续性计划时，请重点关注以下两个关键指标：
-- 恢复时间目标（RTO）：应用在发生中断事件后完全恢复所能接受的最长时间。
-- 恢复点目标（RPO）：在从非计划中断事件中恢复时，应用可容忍丢失的最近数据更新的最长时间间隔。
+- 恢复时间目标（RTO）：应用在发生中断事件后，完全恢复所能容忍的最长时间。
+- 恢复点目标（RPO）：应用在从非计划中断事件恢复时，所能容忍的最近数据 update 的最长时间间隔。
-下表对比了每种高可用性选项的 RTO 和 RPO：
+下表对比了不同高可用选项的 RTO 和 RPO：
-| 高可用性架构 | RTO（停机时间） | RPO（数据丢失） |
-|------------------------|--------------------------|-----------------|
-| 可用区级高可用性 | 近 0 秒 | 0 |
-| 区域级高可用性 | 通常小于 600 秒 | 0 |
\ No newline at end of file
+| 高可用架构 | RTO（停机时间） | RPO（数据丢失） |
+|--------------------------------|-------------------------------|-----------------|
+| 分区高可用 | 近 0 秒 | 0 |
+| 区域高可用 | 通常小于 600 秒 | 0 |
\ No newline at end of file