高可用是企业级数据库的核心要求。TDengine通过多副本、自动故障转移等机制保障服务连续性。
一、高可用架构
1.1 架构组件
┌─────────────────────────────────────────────────────┐
│ 负载均衡器 │
│ (Nginx/HAProxy) │
└──────────────────┬──────────────────────────────────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ taosd │ │ taosd │ │ taosd │
│ Node1 │ │ Node2 │ │ Node3 │
└────────┘ └────────┘ └────────┘
│ │ │
└─────────┼─────────┘
│
┌────┴────┐
│ 存储层 │
│ (多副本) │
└─────────┘
1.2 副本策略
-- 创建三副本数据库
CREATE DATABASE demo REPLICA 3 VGROUPS 10;
-- 查看副本状态
SHOW VNODES;
二、多副本机制
2.1 副本类型
| 副本类型 | 说明 | 适用场景 |
|---|---|---|
| 强同步 | 所有副本写入成功才返回 | 核心业务 |
| 弱同步 | 主副本写入即可返回 | 性能优先 |
| 异步 | 主副本写入即返回 | 日志类数据 |
2.2 Leader选举
TDengine采用Raft协议进行Leader选举:
- 自动选举新Leader
- 数据自动同步
- 对应用透明
三、自动故障转移
3.1 故障检测
-- 查看节点状态
SHOW DNODES;
-- 节点状态
-- offline - 离线
-- online - 在线
-- syncing - 同步中
3.2 故障恢复流程
1. 检测节点故障 (3秒)
2. 标记节点为offline
3. 自动选举新Leader
4. 数据同步到新节点
5. 恢复服务
3.3 恢复时间目标
| 场景 | RTO | RPO |
|---|---|---|
| 单节点故障 | <30秒 | 0 |
| 网络分区 | <1分钟 | <1分钟 |
四、负载均衡
4.1 Vgroup负载均衡
-- 触发均衡
BALANCE VGROUP;
-- 查看均衡状态
SHOW CLUSTER;
4.2 写入负载分配
负载均衡器自动分配写入请求:
- 轮询策略
- 最少连接策略
- IP哈希策略
五、网络配置
5.1 网络隔离
建议使用独立网络:
- 集群内部通信网络
- 客户端接入网络
- 存储网络(分布式存储)
5.2 网络质量要求
| 指标 | 要求 |
|---|---|
| 带宽 | 万兆网络 |
| 延迟 | <1ms |
| 丢包率 | <0.01% |
六、容量规划
6.1 副本数选择
| 业务等级 | 副本数 | 说明 |
|---|---|---|
| 核心业务 | 3 | 高可用保障 |
| 一般业务 | 2 | 成本平衡 |
| 开发测试 | 1 | 仅开发使用 |
6.2 节点规划
建议生产环境至少3个节点:
- 支持三副本部署
- 保证多数派选举
- 避免单点故障
总结
TDengine高可用架构要点:
- 配置合理的副本策略
- 确保网络质量
- 建立监控告警体系
- 定期进行故障演练
- 制定灾备恢复预案
























