当 Cassandra 3.0 中的 TWCS TTL 更改时触发压缩答案

【问题标题】：Trigger compactions when TWCS TTL changes in Cassandra 3.0当 Cassandra 3.0 中的 TWCS TTL 更改时触发压缩
【发布时间】：2018-11-27 15:51:47
【问题描述】：

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

Cassandra 每天都会清理一个包含一个月前过期数据的 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

这个命令列出所有的sstables

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

【问题讨论】：

你桌子上的gc_grace_period 是什么？你什么时候把 TTL 改成 15 天的？
@AlexOtt 是 86400 秒（24 小时），一个多月前我改过了。

标签： cassandra

【解决方案1】：

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

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

编辑：它没有用，Sstable 的数量再次增加。

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

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

【讨论】：