12节点Cassandra生产集群磁盘超85%占用 TTL配置未生效咨询

TTL自动删除旧数据的前提条件 #

• 表级default_time_to_live仅对配置完成后新写入的数据生效，配置前已存储的历史数据不会默认追加该TTL规则，这是当前旧数据未被清理的核心原因
• 写入数据时如果单独指定了行级/列级TTL，会覆盖表级默认TTL，这类数据按单独指定的TTL过期
• 集群所有节点的系统时间必须同步，误差超过TTL阈值会导致过期判断逻辑失效
• 若表开启了CDC（数据变更捕获）功能，过期数据会等待CDC日志达到保留周期后才允许被清理
• gc_grace_seconds设置为3小时的前提下，必须保证集群所有副本节点在3小时内无离线情况，否则会出现已删除数据复活的问题

删除记录后释放磁盘空间的必要操作 #

Cassandra的删除逻辑为标记墓碑而非直接擦除数据，墓碑只有在SSTable合并阶段才会被清理，因此释放空间需要满足以下要求：

• 等待常规compaction自动触发：默认的SizeTieredCompactionStrategy仅在多个相近大小的SSTable达到阈值时才会合并，清理效率偏低
• 若要主动触发，建议执行单表、分时段的增量compaction，不要执行全节点全量compaction

该操作完全不可行，风险极高：

• nodetool compact默认执行全量合并，合并过程中需要临时占用和当前节点待合并SSTable总大小等额的磁盘空间，当前磁盘使用率已经达到85%，极易直接打满磁盘导致节点宕机、数据损坏
• nodetool cleanup的作用是清理不属于当前节点token范围的冗余数据，仅在集群增减节点、调整token分配后会有明显效果，常规运行的集群执行cleanup基本不会释放空间

• 优先快速清理旧数据：如果表为时间分区设计，直接DROP超出保留周期的旧分区，效率远高于TTL/DELETE；如果非分区设计，可使用带时间条件的批量DELETE语句逐步清理旧数据，避免一次性操作压力过大
• 调整合并策略：如果是时序场景的表，将compaction策略修改为TimeWindowCompactionStrategy(TWCS)，可按时间窗口合并SSTable，过期数据会随着整个窗口的SSTable淘汰直接释放，清理效率比默认策略高50%以上
• 更换更高压缩率算法：将表的压缩算法从默认LZ4更换为ZSTD，在CPU开销仅提升5%-10%的前提下，可节省20%-30%的磁盘空间
• 临时清理冗余文件：先删除节点上的过期debug日志、已归档的commitlog、旧版本SSTable备份文件，先腾出部分磁盘空间作为缓冲
• 集群扩容：当前12个节点的负载均处于高位，新增节点可自动分散数据分片，降低单节点的磁盘占用
• 优化数据模型：清理表中无用的冗余字段，拆分存储超大字段，避免单条数据体积过大

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