xxq250
/
homework-jianmu
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: add ha

This commit is contained in:
Shengliang Guan 2024-12-21 13:46:18 +08:00
parent 9488a3f3e4
commit 93fefff5e4
6 changed files with 90 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -4,30 +4,17 @@ sidebar_label: 三副本方案
toc_max_heading_level: 4 toc_max_heading_level: 4
--- ---
本节介绍 TDengine 三副本方案的配置与使用。 本节介绍 TDengine 三副本方案的配置与使用。
TDengine 的三副本方案采用 RAFT 算法来实现数据的一致性，包括元数据和时序数据。一个虚拟节点组（VGroup）构成了一个 RAFT 组；虚拟节点组的虚拟数据节点（Vnode），便是该 RAFT 组的成员节点，也称之为副本。 TDengine 的三副本方案采用 RAFT 算法来实现数据的一致性，包括元数据和时序数据。一个虚拟节点组（VGroup）构成了一个 RAFT 组；虚拟节点组的虚拟数据节点（Vnode），便是该 RAFT 组的成员节点，也称之为副本。
1. 每个 Vnode 都有自己的角色，它们可以是 Follower（跟随者）、Candidate（候选人）、Leader（领导者）。 1. 每个 Vnode 都有自己的角色，它们可以是 Leader（领导者）、Follower（跟随者）、Candidate（候选人）。
2. 每个 Vnode 都维护了一份连续的日志（Log），用于记录数据写入、变更、或删除等操作的所有指令。日志是由一系列有序的日志条目 (Log Entry) 组成，每个 Log Entry 都有唯一的编号（Index），用于标识日志协商或执行的进度。 2. 每个 Vnode 都维护了一份连续的日志（Log），用于记录数据写入、变更、或删除等操作的所有指令。日志是由一系列有序的日志条目 (Log Entry) 组成，每个 Log Entry 都有唯一的编号（Index），用于标识日志协商或执行的进度。
3. Leader 角色的 Vnode 提供读写服务，在故障节点不超过半数的情况下保证集群的高可用性。此外，即使发生了节点重启及 Leader 重新选举等事件后，RAFT 也能够始终保证新产生的 Leader 可以提供已经写入成功的全部完整数据的读写服务。 3. Leader 角色的 Vnode 提供读写服务，在故障节点不超过半数的情况下保证集群的高可用性。此外，即使发生了节点重启及 Leader 重新选举等事件后，RAFT 也能够始终保证新产生的 Leader 可以提供已经写入成功的全部完整数据的读写服务。
4. 每一次对数据库的变更请求（比如 insert），都对应一个 Log Entry。在持续写入数据的过程中，会按照协议机制在每个成员节点上产生完全相同的日志记录，并且以相同的顺序执行数据变更操作，以 WAL 的形式存储在数据文件目录中。 4. 每一次对数据库的变更请求（比如 insert），都对应一个 Log Entry。在持续写入数据的过程中，会按照协议机制在每个成员节点上产生完全相同的日志记录，并且以相同的顺序执行数据变更操作，以 WAL 的形式存储在数据文件目录中。
5. 每一个 Log Entry 携带的 Index，就代表数据变更的版本号；当一个数据写入请求发出后，必定至少过半数节点上完成写入才会把“写入成功”返回给客户端；这部分涉及 Log entry 的两种重要的状态，committed 和 applied。 5. 只有当过半数的节点把该条写入信息追加到文件系统上的 WAL，并且收到确认消息之后，这条 Log entry 才会被 Leader 认为是安全的；此时该日志进入 committed 状态，完成数据的插入，随后该 Log Entry 便被标记为 applied 的状态。
6. 只有当过半数的节点把该条 SQL 的写入信息追加到文件系统上的 WAL，并且收到确认消息之后，这条 Log entry 才会被 Leader 认为是安全的；此时该日志进入 committed 状态，完成数据的插入，随后该 Log Entry 便被标记为 applied 的状态。
<img src={replica3} width="560" alt="多副本工作原理图" /> 多副本工作原理参见 [数据写入与复制流程](../../26-tdinternal/01-arch.md#数据写入与复制流程)
## 方案特点
1. 最小配置的服务器节点数为 3 个
2. 三副本为数据库建库参数，不同数据库可按需选择副本数
3. 支持单副本与三副本之间切换(前提是节点数量满足需求、各节点可用 vnode 数量/内存/存储空间足够)
4. 支持 TDengine 集群的完整特性，包括：读缓存、数据订阅、流计算等
5. 支持 TDengine 所有语言连接器以及连接方式
6. 不支持三副本与双副本之间的切换
7. 不支持三副本切换为双活，除非另外部署一套实例与当前实例组成双活方案
## 集群配置 ## 集群配置
@ -35,10 +22,26 @@ TDengine 的三副本方案采用 RAFT 算法来实现数据的一致性，包
1. 确定服务器节点数量、主机名或域名，配置好所有节点的域名解析：DNS 或 /etc/hosts 1. 确定服务器节点数量、主机名或域名，配置好所有节点的域名解析：DNS 或 /etc/hosts
2. 各节点分别安装 TDengine 企业版服务端安装包，按需编辑好各节点 taos.cfg 2. 各节点分别安装 TDengine 企业版服务端安装包，按需编辑好各节点 taos.cfg
3. 启动各节点 taosd 服务 (其他服务可按需启动：taosadapter/taosx/taoskeeper/taos-explorer) 3. 启动各节点 taosd 服务 (其他服务可按需启动：taosadapter/taosx/taoskeeper/taos-explorer)
4. 登入taos CLI，将所有节点添加入集群 create dnode xxxx
5. 创建三个 mnode create mnode on dnode nn
## 数据库创建 ## 运维命令
### 创建集群
创建三节点的集群
```sql
CREATE dnode <dnode_ep> port <dnode_port>;
CREATE dnode <dnode_ep> port <dnode_port>;
```
创建三副本的 Mnode，保证 Mnode 高可用
```sql
CREATE mnode on dnode <dnode_id>;
CREATE mnode on dnode <dnode_id>;
```
### 数据库创建
创建三副本数据库。DBA 按需创建指定的三副本数据库 创建三副本数据库。DBA 按需创建指定的三副本数据库
@ -46,7 +49,7 @@ TDengine 的三副本方案采用 RAFT 算法来实现数据的一致性，包
create database <dbname> replica 3 vgroups xx buffer xx ... create database <dbname> replica 3 vgroups xx buffer xx ...
``` ```
## 修改数据库副本数 ### 修改数据库副本数
创建了一个单副本数据库后，希望改为三副本时，可通过 alter 命令来实现，反之亦然 创建了一个单副本数据库后，希望改为三副本时，可通过 alter 命令来实现，反之亦然

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

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

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

@ -18,15 +18,14 @@ TDengine 双活系统的部署架构图如下, 其中涉及到三个关键点：
注：下图中仅以一个单机版 TDengine 作为示例，但在实际部署中图中的一个 Host 也可以被任意节点数量的 TDengine 集群代替。 注：下图中仅以一个单机版 TDengine 作为示例，但在实际部署中图中的一个 Host 也可以被任意节点数量的 TDengine 集群代替。
![Active-Standby.png](./Active-Standby.png) ![Active-Standby.png](../pic/Active-Standby.png)
## 配置
### 集群配置 ## 集群配置
双活对 TDengine 集群本身的配置没有任何要求，但对要在双活系统之间同步的数据库的 WAL 保留时长有一定要求，WAL 保留时长越大双活系统的容错率越高；如果备节点宕机时长超过主节点上的 WAL 保留时长，必定会导致备节点上有数据缺失；如果备节点宕机时长虽未超过主节点上的 WAL 保留时长，也有一定概率丢失数据，取决于接近的程度以及数据同步的速度。 双活对 TDengine 集群本身的配置没有任何要求，但对要在双活系统之间同步的数据库的 WAL 保留时长有一定要求，WAL 保留时长越大双活系统的容错率越高；如果备节点宕机时长超过主节点上的 WAL 保留时长，必定会导致备节点上有数据缺失；如果备节点宕机时长虽未超过主节点上的 WAL 保留时长，也有一定概率丢失数据，取决于接近的程度以及数据同步的速度。
### 客户端配置 ## 客户端配置
目前只有 Java 连接器在 WebSocket 连接模式下支持双活，其配置示例如下 目前只有 Java 连接器在 WebSocket 连接模式下支持双活，其配置示例如下
@ -51,11 +50,11 @@ connection = DriverManager.getConnection(url, properties);
| PROPERTY_KEY_RECONNECT_INTERVAL_MS | 重连的时间间隔，单位毫秒：默认 2000 毫秒，也就是 2 秒；最小值为 0， 表示立即重试；最大值不做限制 | | PROPERTY_KEY_RECONNECT_INTERVAL_MS | 重连的时间间隔，单位毫秒：默认 2000 毫秒，也就是 2 秒；最小值为 0， 表示立即重试；最大值不做限制 |
| PROPERTY_KEY_RECONNECT_RETRY_COUNT | 每节点最多重试次数：默认值为 3；最小值为 0，表示不进行重试；最大值不做限制 | | PROPERTY_KEY_RECONNECT_RETRY_COUNT | 每节点最多重试次数：默认值为 3；最小值为 0，表示不进行重试；最大值不做限制 |
### 约束条件 ## 约束条件
1. 应用程序不能使用订阅接口，如果配置了双活参数会导致创建消费者失败。 1. 应用程序不能使用订阅接口，如果配置了双活参数会导致创建消费者失败
2. 不建议应用程序使用参数绑定的写入和查询方式，如果使用应用需要自己解决连接切换后的相关对象失效问题。 2. 不建议应用程序使用参数绑定的写入和查询方式，如果使用应用需要自己解决连接切换后的相关对象失效问题
3. 在双活场景下，不建议用户应用程序显示调用 use database，应该在连接参数中指定 database。 3. 在双活场景下，不建议用户应用程序显示调用 use database，应该在连接参数中指定 database
4. 双活的两端集群必须同构（即数据库的命名和所有配置参数以及用户名密码和权限设置等完全相同） 4. 双活的两端集群必须同构（即数据库的命名和所有配置参数以及用户名密码和权限设置等完全相同）
5. 只支持 WebSocket 连接模式 5. 只支持 WebSocket 连接模式

22
docs/zh/08-operation/18-ha/index.md
View File

@ -5,21 +5,21 @@ title: High availability
TDengine 作为分布式时序数据库，支持高可用特性。默认高可用方案为基于 RAFT 协议的标准三副本方案；为适应不同用户场景的需要，提供基于 RAFT 协议改造的双副本方案；为满足传统双机主备架构的需求，提供基于 WAL 数据同步的双活方案。 TDengine 作为分布式时序数据库，支持高可用特性。默认高可用方案为基于 RAFT 协议的标准三副本方案；为适应不同用户场景的需要，提供基于 RAFT 协议改造的双副本方案；为满足传统双机主备架构的需求，提供基于 WAL 数据同步的双活方案。
- 标准三副本方案：时序数据的副本数目为 3，确保了最高的可用性，成本也最高 - 标准三副本方案：时序数据的副本数目为 3，确保了最高的可用性，成本也最高。
- 双副本结合 Arbitrator 方案：时序数据的副本数目为 2，但节点数目至少为 3，以确保高可用性和良好的数据一致性，可显著降低成本；与三副本方案相比，此方案在显著降低成本的同时，依然保持了较高的可用性 - 双副本结合 Arbitrator 方案：时序数据的副本数目为 2，但节点数目至少为 3，以确保高可用性和良好的数据一致性，可显著降低成本；与三副本方案相比，此方案在显著降低成本的同时，依然保持了较高的可用性。
- 双活方案：可仅部署两个节点，高可用性较好，数据一致性弱（最终一致性） - 双活方案：可仅部署两个节点，高可用性较好，数据一致性弱（最终一致性）。
以下为三种方案的特点： 以下为三种方案的特点：
| # | **三副本** | **双副本** | **双活** | | # | **三副本** | **双副本** | **双活** |
|:--|:----------|:----------|:--------| |:--|:----------|:----------|:--------|
| 集群数目 | 部署一个集群 | 部署一个集群 | 部署两个不同集群 | | **集群数目** | 部署一个集群 | 部署一个集群 | 部署两个不同集群 |
| 最小节点数 | 三个数据节点 | 两个数据节点，一个仲裁节点 | 两个数据节点 | | **最小节点数** | 三个数据节点 | 两个数据节点，一个仲裁节点 | 两个数据节点 |
| 选主原理 | Raft 协议 | 管理节点仲裁选主 | 无需选主 | | **选主原理** | Raft 协议 | 管理节点仲裁选主 | 无需选主 |
| 同步原理 | Raft 协议 | Raft 协议 | 通过 taosX 进行数据同步 | | **同步原理** | Raft 协议 | Raft 协议 | 通过 taosX 进行数据同步 |
| 同步延迟 | 无延迟 | 无延迟 | 依赖于 taosX 的同步速度，秒级延迟 | | **同步延迟** | 无延迟 | 无延迟 | 依赖于 taosX 的同步速度，秒级延迟 |
| 数据安全性 | 无数据丢失 | 无数据丢失 | 依赖于 WAL 的保存时长 | | **数据安全性** | 无数据丢失 | 无数据丢失 | 依赖于 WAL 的保存时长 |
| 数据一致性 | RAFT 一致性 | RAFT 一致性 | 最终一致性 | | **数据一致性** | RAFT 一致性 | RAFT 一致性 | 最终一致性 |
| 高可用性 | 任一节点宕机不影响服务 | 任一节点宕机不影响服务，但不能处理连续宕机场景 | 一个实例存活即可提供服务 | | **高可用性** | 任一节点宕机不影响服务 | 任一节点宕机不影响服务，但不能处理连续宕机场景 | 一个实例存活即可提供服务 |

BIN
docs/zh/08-operation/Active-Standby.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 161 KiB

BIN
docs/zh/08-operation/pic/replica2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 103 KiB