From 11749a9fb3da4cb59d144ea82e58f3dbf567a9c0 Mon Sep 17 00:00:00 2001 From: Shengliang Guan Date: Sat, 21 Dec 2024 18:45:50 +0800 Subject: [PATCH] docs: update ha --- docs/zh/08-operation/18-ha/01-replica3.md | 26 +++++++++++------------ docs/zh/08-operation/18-ha/02-replica2.md | 17 +++++++-------- docs/zh/08-operation/18-ha/03-dual.md | 6 ++---- docs/zh/08-operation/18-ha/index.md | 8 +++---- 4 files changed, 26 insertions(+), 31 deletions(-) diff --git a/docs/zh/08-operation/18-ha/01-replica3.md b/docs/zh/08-operation/18-ha/01-replica3.md index 5a16d3f152bf..fee19a0afe1d 100644 --- a/docs/zh/08-operation/18-ha/01-replica3.md +++ b/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,7 +41,7 @@ CREATE mnode on dnode ; ### 数据库创建 -创建三副本数据库。DBA 按需创建指定的三副本数据库 +创建三副本的数据库 ```sql create database replica 3 vgroups xx buffer xx ... @@ -51,7 +49,7 @@ create database replica 3 vgroups xx buffer xx ... ### 修改数据库副本数 -创建了一个单副本数据库后，希望改为三副本时，可通过 alter 命令来实现，反之亦然 +创建了单副本数据库后，如果希望改为三副本时，可通过 alter 命令来实现，反之亦然 ```sql alter database replica 3|1 @@ -65,4 +63,4 @@ alter database replica 3|1 ### 2. 创建三副本数据库或 split vgroup 时，报错：DB error: Vnodes exhausted - 服务器可用 Vnodes 不足：原因是某些服务器节点可用 Vnodes 数少于建库或 split vgroup 的需求数。 -- 解决方案：调整服务器 CPU 数量、SupportVnodes 数量，满足建库要求。 \ No newline at end of file +- 解决方案：调整服务器 CPU 数量、SupportVnodes 配置参数，满足建库要求。 \ No newline at end of file diff --git a/docs/zh/08-operation/18-ha/02-replica2.md b/docs/zh/08-operation/18-ha/02-replica2.md index 67a071c7e099..7f3eb2fe5c54 100644 --- a/docs/zh/08-operation/18-ha/02-replica2.md +++ b/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,7 +49,7 @@ CREATE mnode on dnode ; ### 数据库创建 -创建双副本数据库。DBA 按需创建指定的双副本数据库 +按需创建双副本数据库 ```sql create database replica 2 vgroups xx buffer xx ... @@ -58,7 +57,7 @@ create database replica 2 vgroups xx buffer xx ... ### 修改数据库副本数 -创建了一个单副本数据库后，希望改为双副本时，可通过alter命令来实现。反之亦然 +创建了单副本数据库后，希望改为双副本时，可通过 alter 命令来实现，反之亦然 ```sql alter database replica 2|1 diff --git a/docs/zh/08-operation/18-ha/03-dual.md b/docs/zh/08-operation/18-ha/03-dual.md index b19b8e8bc582..20565bd5622b 100644 --- a/docs/zh/08-operation/18-ha/03-dual.md +++ b/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，意为”主从“或”主备“，本文档中可能会出现混用的情况。 diff --git a/docs/zh/08-operation/18-ha/index.md b/docs/zh/08-operation/18-ha/index.md index c40dfe448a17..d482646ddd4b 100644 --- a/docs/zh/08-operation/18-ha/index.md +++ b/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，以确保高可用性和良好的数据一致性，可显著降低成本。与三副本方案相比，此方案在显著降低成本的同时，依然保持了较高的可用性。 +- 双活方案：可仅部署两个节点，高可用性较好，数据一致性较弱（最终一致性）。 以下为三种方案的特点：