Cassandra v3.0.15集群大文件删除及磁盘空间回收安全方案咨询

API 探路者

2026-7-9

安全清理过期数据并回收磁盘空间的落地方案

一、优先处理使用DateTieredCompactionStrategy（DTC）的表

这张表当前max_sstable_age_days=365，导致超过1年的SST无法被自动压缩，是清理的核心目标：

分析SST文件时间范围
在每个节点上，使用sstablemetadata工具逐个检查该表的SST文件，确认哪些SST的所有数据时间戳都早于2年前：
```
$CASSANDRA_HOME/bin/sstablemetadata /var/lib/cassandra/data/[keyspace]/[table]-[uuid]/[sst-file].db
```
输出中会显示Min timestamp和Max timestamp，筛选出两者都早于2年前的SST。
单节点分批清理旧SST
为避免影响集群可用性，每次只操作一个节点：
- 对目标节点执行nodetool drain，将内存中的数据刷入磁盘，暂停该节点的写入服务。
- 手动删除筛选出的全过期SST文件（只删完全不含有效数据的文件，不要误删包含新数据的SST）。
- 启动该节点，待节点完全加入集群后，对该表执行nodetool repair --full，确保集群数据一致性（其他节点的对应副本后续按同样步骤清理）。
调整DTC参数触发自动清理
修改该表的max_sstable_age_days为730（2年），让超过2年的SST自动纳入压缩范围：
```
ALTER TABLE [keyspace].[table] WITH compaction = {'class': 'DateTieredCompactionStrategy', 'max_sstable_age_days': 730};
```
随后执行nodetool compact -t DateTieredCompactionStrategy [keyspace] [table]，触发一次针对旧SST的压缩，压缩过程中会自动清理过期数据，且不会产生大量墓碑。

LCS的分层压缩会自动合并旧数据，但需调整参数避免磁盘空间耗尽：

临时缩短gc_grace_seconds
将两张LCS表的gc_grace_seconds临时调整为86400（1天），压缩时会更快清理墓碑：
```
ALTER TABLE [keyspace].[table1] WITH gc_grace_seconds = 86400;
ALTER TABLE [keyspace].[table2] WITH gc_grace_seconds = 86400;
```
注：不要设为0，避免节点离线时出现数据不一致；操作前确保所有节点都在线且状态正常。
分批触发分层压缩
由于磁盘空间有限，不要直接执行全表压缩，而是按层级分批压缩：
```
nodetool compact -t LeveledCompactionStrategy -level [n] [keyspace] [table]
```
从最高层级（最旧数据所在层级）开始，逐层压缩，每次压缩完成后等待磁盘空间释放，再进行下一层级。压缩过程中监控磁盘使用率，若剩余空间低于3%，立即暂停操作，待空间释放后继续。

恢复gc_grace_seconds
待所有旧数据清理完成后，将gc_grace_seconds恢复为原来的10天：

ALTER TABLE [keyspace].[table1] WITH gc_grace_seconds = 864000;
ALTER TABLE [keyspace].[table2] WITH gc_grace_seconds = 864000;

操作期间，持续用df -h监控磁盘使用率，若剩余空间不足则暂停当前任务，待空间释放后再继续。
若压缩产生的临时文件占用过多空间，可临时降低压缩速度：
```
nodetool setcompactionthroughput 10
```
待空间压力缓解后再调回原值（默认一般为16或32）。

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