TDengine有哪些不可用场景？集群高可用如何有效保障？

除脑裂、主节点选举失败外的常见不可用/core dump场景 #

• 数据文件损坏：磁盘故障、意外断电导致TSDB数据文件、元数据文件被篡改或完整性校验失败时，节点启动会直接触发core dump，严重时对应集群分片完全无法读写
• 磁盘空间耗尽：WAL日志、持久化数据文件、系统日志持续写入占满磁盘后，所有写入请求会直接失败，进程无写入权限时会异常退出
• 集群仲裁节点不足：多副本集群故障离线节点数超过总节点数的半数时，剩余节点无法达成共识仲裁，整个集群会拒绝所有读写请求
• 资源超出负载阈值：单条查询扫描数据量过大、同时触发大量聚合计算，或写入QPS远超集群配置上限，导致CPU/内存占满后进程被系统OOM kill，出现core dump
• 核心配置错误：numOfVnodes、replica等核心参数配置不符合集群硬件规格，或跨版本升级后旧配置与新版本不兼容，会导致节点启动直接崩溃
• 长时间网络分区：跨节点网络延迟超过timeToWaitForRPC配置阈值，节点间心跳、数据同步完全中断，对应分片副本会离线无法提供服务
• 版本逻辑bug触发：部分旧版本存在的逻辑漏洞，比如特定格式写入请求、非法SQL查询触发内存越界，会直接导致进程core dump

TDengine集群高可用保障方案 #

• 合理配置节点与副本：生产环境优先使用3副本或5副本配置，跨机架/可用区部署节点，避免单机房故障导致超过半数节点离线，满足仲裁法定人数要求
• 完善监控告警体系：对节点进程状态、CPU/内存/磁盘使用率、WAL积压量、分片在线状态、写入成功率、查询延迟等核心指标做实时监控，阈值触发时及时告警处理
• 数据存储与备份优化：数据目录使用高可靠SSD存储，WAL日志目录与数据目录分开挂载，避免日志占满磁盘影响数据写入，定期执行全量数据备份
• 参数与版本适配：根据集群硬件规格、业务并发量调整maxSQLLength、queryBufferSize、numOfThreadsPerVnode等核心参数，生产环境优先选择经过长期验证的稳定版，升级前先在测试环境验证配置兼容性
• 故障容灾预案配置：提前梳理节点故障、网络分区、磁盘满等常见故障的处理流程，配置节点故障自动拉起脚本，特殊场景下可通过taos命令行手动切换主节点、下线故障节点快速恢复集群可用性
• 流量管控拦截：在接入层配置限流策略，避免突发高并发写入、超大查询请求打满集群资源，同时做好SQL校验拦截非法请求
• 定期集群巡检：定期检查节点运行日志是否有异常报错、数据副本是否一致、磁盘是否存在坏道，提前排查潜在故障点

内容的提问来源于stack exchange，提问作者naissance