在Cassandra 3.0中TWCS TTL发生变化时触发压缩

我在cassandra中有一个表，我使用客户端TTL=1个月保存数据（表TTL为0），该表配置了时间窗口压缩策略

每天卡桑德拉都会清理一张包含一个月前过期数据的sstable。 最近我把客户端TTL改为15天，我希望cassandra在某个时候每天清理两个SSTABLE，然后释放空间。但它每天清理一个sstable，并保留15天的死数据

我怎么知道

for f in /data/cassandra/data/keyspace/table-*/*Data.db; do meta=$(sudo sstablemetadata $f); echo -e "Max:" $(date --date=@$(echo "$meta" | grep Maximum\ time | cut -d" " -f3| cut -c 1-10) '+%m/%d/%Y') "Min:" $(date --date=@$(echo "$meta" | grep Minimum\ time | cut -d" " -f3| cut -c 1-10) '+%m/%d/%Y') $(echo "$meta" | grep droppable) ' \t ' $(ls -lh $f | awk '{print $5" "$6" "$7" "$8" "$9}'); done | sort

此命令列出所有SST表

Max: 05/19/2018 Min: 05/18/2018 Estimated droppable tombstones: 0.9876591095477787        84G May 21 02:59 /data/cassandra/data/pcc/data_history-c46a3220980211e7991e7d12377f9342/mc-218473-big-Data.db
Max: 05/20/2018 Min: 05/19/2018 Estimated droppable tombstones: 0.9875830312750179        84G May 22 15:25 /data/cassandra/data/pcc/data_history-c46a3220980211e7991e7d12377f9342/mc-221915-big-Data.db
Max: 05/21/2018 Min: 05/20/2018 Estimated droppable tombstones: 0.9876636061230402        85G May 23 13:56 /data/cassandra/data/pcc/data_history-c46a3220980211e7991e7d12377f9342/mc-224302-big-Data.db
...

目前，我一直在使用JMX手动触发压缩，但我希望所有压缩都像正常情况下一样被擦除

run -b org.apache.cassandra.db:type=CompactionManager forceUserDefinedCompaction /data/cassandra/data/keyspace/sstable_path

---

我想我明白了。必须在最旧和最新的sstable上运行手动压缩，所有内容都已过期，两个sstable同时运行。 过了几天，一切都干净了

我怎么知道它在运行？因为当我尝试在中间的任何其他sstable上运行ForceUserDefinedCompression时，它总是返回null

编辑： 它不起作用，再次Sstable计数不断增加

编辑： 使用sstableexpiredblockers指向阻塞剩余压缩的sstables。手动压实后，它会自动压实其余部分

---

在8个节点中的一个节点上，阻塞的sstable在压缩后没有解锁，因此“nodetool scrub”完成了任务（它会清理所有sstable）。

您的表上的

gc\u宽限期是什么？你什么时候把TTL改为15天的？@AlexOtt现在是86400秒（24小时），我一个多月前就改了。