TiDB运维实践中，磁盘空间不足会直接影响对应目录下的组件可用性。由于 TiDB 架构中包含 TiKV、TiDB、PD、TiFlash、Prometheus等多个组件，实际部署时往往存在多组件共享使用目录的情况。借此想向各位请教：
1、空间暴增风险：日常运维中，哪些组件（如 TiKV 数据目录、Prometheus 监控数据、TiCDC 日志等）的磁盘占用最容易快速增长？
2、限制手段：针对这些组件的空间增长，有哪些有效的限制或清理策略（如保留策略、配额限制）？
3、隔离建议：从故障域和性能影响角度，哪些组件最建议进行独立的目录隔离部署？
空间问题就是做好监控吧。
各个组件的日志确保定期清除。
1 个赞
优先物理磁盘隔离，无法加盘时至少按组件独立分区挂载，配合磁盘配额兜底；
1 个赞
| 组件 | 空间暴增风险 | 核心限制手段 | 隔离建议 |
|---|---|---|---|
| TiKV | 数据 + RocksDB 放大 + 后台任务 | raftstore.capacity + 预留 20% + 水位 <80% | 数据/日志目录分离；多实例时分盘 |
| TiFlash | 列式副本 + 实时缓冲写入 | 多盘部署，第一块盘 ≥ 总容量 10% | 与 TiKV 节点隔离；最低限度不同磁盘 |
| Prometheus | 时序数据线性增长 | –storage.tsdb.retention（默认 15d） | 与 PD 数据目录必须使用独立文件系统 |
| TiCDC | 排序目录 + 大事务写盘 | gc-ttl + sort-dir 配置 | sort-dir 独立 SSD 磁盘 |
| TiDB 临时空间 | Fast DDL / IMPORT INTO | 单独挂载临时磁盘 | 独立 SSD（100 GB+） |
| GC 历史版本 | 长事务 / TiCDC 阻塞导致 | tidb_gc_life_time / tidb_gc_enable | — |
1 个赞
HTAP核心是TiFlash列存和TiKV行存间的Raft Learner异步复制机制。
定期清理日志，我们系统要求日志只需要保留最近六个月的
空间暴涨常见来源：TiKV 数据+Raft 日志、Prometheus 长期 retention、TiCDC/Binlog 日志、TiFlash 存储。策略：监控 retention 调短、TiKV 关注 compaction 和 GC；日志组件配 rotate+清理。隔离上 TiKV/TiFlash 数据目录务必独立，不要和 OS/PD/TiDB 混盘；Prometheus 单独盘或限制 TSDB 保留。混部时任一组件打满盘会导致同盘其他组件不可用，生产建议分盘+告警阈值。
1 个赞
TiKV 必须物理隔离（最高优先级）
1 个赞
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。