Merge pull request #29260 from taosdata/fix/internal

docs: add ha

docs/zh/08-operation/18-ha/01-replica3.md

@@ -4,24 +4,22 @@ sidebar_label: 三副本方案
 toc_max_heading_level: 4
 ---
 
-本节介绍 TDengine 三副本方案的配置与使用。
+TDengine 的三副本方案采用 RAFT 算法来实现数据的一致性，包括元数据和时序数据。一个虚拟节点组（VGroup）构成了一个 RAFT 组；VGroup 中的虚拟节点（Vnode），便是该 RAFT 组的成员节点，也称之为副本。
 
-TDengine 的三副本方案采用 RAFT 算法来实现数据的一致性，包括元数据和时序数据。一个虚拟节点组（VGroup）构成了一个 RAFT 组；虚拟节点组的虚拟数据节点（Vnode），便是该 RAFT 组的成员节点，也称之为副本。
-
-1. 每个 Vnode 都有自己的角色，它们可以是 Leader（领导者）、Follower（跟随者）、Candidate（候选人）。
-2. 每个 Vnode 都维护了一份连续的日志（Log），用于记录数据写入、变更、或删除等操作的所有指令。日志是由一系列有序的日志条目 (Log Entry) 组成，每个 Log Entry 都有唯一的编号（Index），用于标识日志协商或执行的进度。
-3. Leader 角色的 Vnode 提供读写服务，在故障节点不超过半数的情况下保证集群的高可用性。此外，即使发生了节点重启及 Leader 重新选举等事件后，RAFT 也能够始终保证新产生的 Leader 可以提供已经写入成功的全部完整数据的读写服务。
-4. 每一次对数据库的变更请求（比如 insert），都对应一个 Log Entry。在持续写入数据的过程中，会按照协议机制在每个成员节点上产生完全相同的日志记录，并且以相同的顺序执行数据变更操作，以 WAL 的形式存储在数据文件目录中。
-5. 只有当过半数的节点把该条写入信息追加到文件系统上的 WAL，并且收到确认消息之后，这条 Log entry 才会被 Leader 认为是安全的；此时该日志进入 committed 状态，完成数据的插入，随后该 Log Entry 便被标记为 applied 的状态。
+1. 每个 Vnode 都有自己的角色，可以是 Leader（领导者）、Follower（跟随者）、Candidate（候选人）。
+2. 每个 Vnode 都维护了一份连续的日志，用于记录数据写入、变更、或删除等操作的所有指令。日志是由一系列有序的日志条目组成，每条日志都有唯一的编号，用于标识日志协商或执行的进度。
+3. Leader 角色的 Vnode 提供读写服务，在故障节点不超过半数的情况下保证集群的高可用性。此外，即使发生了节点重启及 Leader 重新选举等事件后，RAFT 协议也能够始终保证新产生的 Leader 可以提供已经写入成功的全部完整数据的读写服务。
+4. 每一次对数据库的变更请求（比如数据写入），都对应一条日志。在持续写入数据的过程中，会按照协议机制在每个成员节点上产生完全相同的日志记录，并且以相同的顺序执行数据变更操作，以 WAL 文件的形式存储在数据文件目录中。
+5. 只有当过半数的节点把该条日志追加到 WAL 文件，并且收到确认消息之后，这条日志才会被 Leader 认为是安全的；此时该日志进入 committed 状态，完成数据的插入，随后该日志被标记为 applied 的状态。
 
 多副本工作原理参见 [数据写入与复制流程](../../26-tdinternal/01-arch.md#数据写入与复制流程)   
 
 ## 集群配置
 
-三副本要求集群至少配置三个服务器节点，基本部署与配置步骤如下
+三副本要求集群至少配置三个服务器节点，基本部署与配置步骤如下：
 1. 确定服务器节点数量、主机名或域名，配置好所有节点的域名解析：DNS 或 /etc/hosts
-2. 各节点分别安装 TDengine 企业版服务端安装包，按需编辑好各节点 taos.cfg
-3. 启动各节点 taosd 服务 (其他服务可按需启动：taosadapter/taosx/taoskeeper/taos-explorer)
+2. 各节点分别安装 TDengine 服务端安装包，按需编辑好各节点 taos.cfg
+3. 启动各节点 taosd 服务，其他服务可按需启动（taosadapter/taosx/taoskeeper/taos-explorer)
 
 ## 运维命令
 
@@ -43,15 +41,15 @@ CREATE mnode on dnode <dnode_id>;
 
 ### 数据库创建
 
-创建三副本数据库。DBA 按需创建指定的三副本数据库
+创建三副本的数据库
 
 ```sql
 create database <dbname> replica 3 vgroups xx buffer xx ...
 ```
 
 ### 修改数据库副本数
 
-创建了一个单副本数据库后，希望改为三副本时，可通过 alter 命令来实现，反之亦然
+创建了单副本数据库后，如果希望改为三副本时，可通过 alter 命令来实现，反之亦然
 
 ```sql
 alter database <dbname> replica 3|1
@@ -65,4 +63,4 @@ alter database <dbname> replica 3|1
 
 ### 2. 创建三副本数据库或 split vgroup 时，报错：DB error: Vnodes exhausted
 - 服务器可用 Vnodes 不足：原因是某些服务器节点可用 Vnodes 数少于建库或 split vgroup 的需求数。
-- 解决方案：调整服务器 CPU 数量、SupportVnodes 数量，满足建库要求。
+- 解决方案：调整服务器 CPU 数量、SupportVnodes 配置参数，满足建库要求。

docs/zh/08-operation/18-ha/02-replica2.md

@@ -4,9 +4,7 @@ sidebar_label: 双副本方案
 toc_max_heading_level: 4
 ---
 
-本节介绍 TDengine 双副本方案的配置与使用。
-
-部分用户期望在保证一定可靠性、可用性条件下，尽可能压缩部署成本。为此，TDengine 提出基于 Arbitrator 的双副本方案，可提供集群中**只有单个服务故障且不出现连续故障**的容错能力。
+部分用户期望在保证一定可靠性、可用性条件下，尽可能压缩部署成本。为此，TDengine 提出基于 Arbitrator 的双副本方案，可提供集群中**只有单个服务故障且不出现连续故障**的容错能力。双副本方案是 TDengine Enterprise 特有功能，在 3.3.0.0 版本中第一次发布，建议使用最新版本。
 
 双副本选主由高可用的 Mnode 提供仲裁服务，不由 Raft 组内决定。
 1. Arbitrator：仲裁服务，不存储数据，VGroup 因某一 Vnode 故障而无法提供服务时，Arbitrator 可根据数据同步情况指定 VGroup 内另一 Vnode 成为 Assigned Leader
@@ -18,15 +16,16 @@ toc_max_heading_level: 4
 
 双副本要求集群至少配置三个节点，基本部署与配置步骤如下：
 1. 确定服务器节点数量、主机名或域名，配置好所有节点的域名解析：DNS 或 /etc/hosts
-2. 各节点分别安装 TDengine 企业版服务端安装包，按需编辑好各节点 taos.cfg，选择其中一个节点作为仲裁节点，该节点可配置为仅部署 Mnode（将 SupportVnodes 参数设置为 0），除提供仲裁服务之外，不存储时序数据
-3. 启动各节点 taosd 服务 (其他服务可按需启动：taosadapter/taosx/taoskeeper/taos-explorer)
+2. 各节点分别安装 TDengine **企业版**服务端安装包，按需编辑好各节点 taos.cfg
+3. 可选择其中一个节点仅提供仲裁服务（部署 Mnode），将 SupportVnodes 参数设置为 0，表示不存储时序数据；该占用资源较少，仅需 1~2 核，且可与其他应用共用
+4. 启动各节点 taosd 服务，其他服务可按需启动（taosadapter/taosx/taoskeeper/taos-explorer)
 
 ## 约束条件
-1. 最小配置的服务器节点数为 2+1 个，其中两个数据节点，一个仲裁节点；仲裁节点可与其他应用共用，但需与前两个数据节点在同一网段；该节点占用资源少， 仅 1~2 核；如部署 3 个以上数据节点，无需单独部署仲裁节点
+1. 最小配置的服务器节点数为 2+1 个，其中两个数据节点，一个仲裁节点
 2. 双副本为数据库建库参数，不同数据库可按需选择副本数
 3. 支持 TDengine 集群的完整特性，包括：读缓存、数据订阅、流计算等
 4. 支持 TDengine 所有语言连接器以及连接方式
-5. 支持单副本与双副本之间切换（前提是节点数量满足需求、各节点可用 vnode 数量/内存/存储空间足够）
+5. 支持单副本与双副本之间切换（前提是节点数量满足需求、各节点可用 Vnode 数量/内存/存储空间足够）
 6. 不支持双副本与三副本之间的切换
 7. 不支持双副本切换为双活，除非另外部署一套实例与当前实例组成双活方案
 
@@ -50,15 +49,15 @@ CREATE mnode on dnode <dnode_id>;
 
 ### 数据库创建
 
-创建双副本数据库。DBA 按需创建指定的双副本数据库
+按需创建双副本数据库
 
 ```sql
 create database <dbname> replica 2 vgroups xx buffer xx ...
 ```
 
 ### 修改数据库副本数
 
-创建了一个单副本数据库后，希望改为双副本时，可通过alter命令来实现。反之亦然
+创建了单副本数据库后，希望改为双副本时，可通过 alter 命令来实现，反之亦然
 
 ```sql
 alter database <dbname> replica 2|1

docs/zh/08-operation/18-ha/03-dual.md

@@ -1,11 +1,9 @@
 ---
-title: 双活系统
-sidebar_label: 双活系统
+title: 双活方案
+sidebar_label: 双活方案
 toc_max_heading_level: 4
 ---
 
-本节介绍 TDengine 双活系统的配置和使用。
-
 部分用户因为部署环境的特殊性只能部署两台服务器，同时希望实现一定的服务高可用和数据高可靠。本文主要描述基于数据复制和客户端 Failover 两项关键技术的 TDengine 双活系统的产品行为，包括双活系统的架构、配置、运维等。TDengine 双活既可以用于前面所述资源受限的环境，也可用于在两套 TDengine 集群（不限资源）之间的灾备场景。双活是 TDengine Enterprise 特有功能，在 3.3.0.0 版本中第一次发布，建议使用最新版本。
 
 双活系统的定义是：业务系统中有且仅有两台服务器，其上分别部署一套服务，在业务层看来这两台机器和两套服务是一个完整的系统，对其中的细节业务层不需要感知。双活中的两个节点通常被称为 Master-Slave，意为”主从“或”主备“，本文档中可能会出现混用的情况。

docs/zh/08-operation/18-ha/index.md

@@ -1,13 +1,13 @@
 ---
-sidebar_label: HA
-title: High availability
+sidebar_label: 高可用
+title: 高可用
 ---
 
 TDengine 作为分布式时序数据库，支持高可用特性。默认高可用方案为基于 RAFT 协议的标准三副本方案；为适应不同用户场景的需要，提供基于 RAFT 协议改造的双副本方案；为满足传统双机主备架构的需求，提供基于 WAL 数据同步的双活方案。
 
 - 标准三副本方案：时序数据的副本数目为 3，确保了最高的可用性，成本也最高。
-- 双副本结合 Arbitrator 方案：时序数据的副本数目为 2，但节点数目至少为 3，以确保高可用性和良好的数据一致性，可显著降低成本；与三副本方案相比，此方案在显著降低成本的同时，依然保持了较高的可用性。
-- 双活方案：可仅部署两个节点，高可用性较好，数据一致性弱（最终一致性）。
+- 双副本结合 Arbitrator 方案：时序数据的副本数目为 2，但节点数目至少为 3，以确保高可用性和良好的数据一致性，可显著降低成本。与三副本方案相比，此方案在显著降低成本的同时，依然保持了较高的可用性。
+- 双活方案：可仅部署两个节点，高可用性较好，数据一致性较弱（最终一致性）。
 
 以下为三种方案的特点：