集群与高可用
InfluxDB 的高可用能力不能脱离产品版本讨论。OSS 1.x/2.x 通常是单节点产品；InfluxDB 3 Core 也不应直接按企业集群理解。多节点复制、对象存储和独立计算组件属于 Enterprise、Clustered 或 Cloud 等对应产品能力。
能力边界
| 部署 | 典型定位 | 高可用判断 |
|---|---|---|
| InfluxDB OSS 1.x/2.x | 自托管单节点 | 依赖备份、外部重启和恢复，不具备原生多节点自动接管 |
| InfluxDB 3 Core | 单机开源时序引擎 | 适合单节点与边缘场景，能力以 Core 文档为准 |
| InfluxDB 3 Enterprise | 自托管企业版本 | 提供面向生产的扩展与高可用能力，按授权和版本核对 |
| InfluxDB Clustered / Cloud | 分离组件与对象存储架构 | 由服务组件、副本、Catalog 和对象存储共同保证 |
InfluxDB 3 分布式组件
组件分离后，可靠性不再只是给单个进程加副本。需要分别设计：
- Router、Ingester、Querier 和 Compactor 的副本与调度。
- Catalog Store 的备份、复制和故障恢复。
- Object Store 的持久性、版本控制和生命周期策略。
- 最近尚未进入 Parquet 数据的复制与恢复保证。
- 身份认证、Token、网络和负载均衡入口。
选型指标
| 指标 | 问题 |
|---|---|
| RPO | 节点或区域故障允许丢失多少最近数据 |
| RTO | 查询和写入多久恢复，是否允许只读降级 |
| 写入可用性 | 部分组件或对象存储异常时能否继续接收数据 |
| 查询可用性 | 最近数据与历史数据是否有不同可用边界 |
| 故障域 | 组件、Catalog 和 Object Store 是否真正跨域 |
| 成本 | 对象请求、网络、缓存和长期 Parquet 存储成本 |