我的表启用了时间窗口压缩策略 (TWCS)，出于某种原因，我有很多带有墓碑的 SStable。
当我对单个 sstable 运行手动压缩时，它不会被删除。如果我运行一个 reapir，它会将所有 sstables 加入一个，这会破坏 TWCS。
根据nodetool scrub命令的文档：
Scrub 会自动丢弃损坏的数据并删除任何已超过表的 gc_grace 周期的墓碑行。
这会加入所有的 sstables 吗？
【问题讨论】：
简短的回答：磨砂没有加入 sstables。
长答案：继续阅读。
我检查了 Cassandra 3.11.2 中的代码，但 3.0 和 2.2 上的代码相似。
使用压缩线程并行清理 sstable，每个线程清理一个 sstable。
正如您在ColumnFamilyStore.java 中看到的，清理命令是使用CompactionManager 线程运行的。
要检查的有趣函数是parallelAllSSTableOperation。属于该表的所有实时 sstables（不包括标记为可疑的那些 - 例如由于压缩期间的一些异常）都被标记为压缩，在该表上运行的所有压缩都是 paused 并且针对 each sstable 执行操作，在并行。
在清理的情况下，操作是scrubOne，它调用Scrubber.scrub()。这个废弃了旧的 sstable 并创建了一个包含活动行的新 sstable。
在parallelAllSSTableOperation 结束时标记为compacting 的sstables 列表应该为空并且操作成功。不执行 sstables 的连接。
因此，您可以看到清理工具具有侵入性：它会淘汰旧的 sstable，丢弃墓碑并将活动行保留在新的 sstable 中。
我希望这会有所帮助，而且我没有错过任何东西 :)。
【讨论】：