Cassandra 2.1.14启用TWCS后旧SSTable无法驱逐问题咨询

这是TWCS搭配TTL使用时很容易碰到的典型问题，结合你的场景（只写入带TTL的行、从不更新），我来逐一解答你的疑问：

1. 为什么极新的SSTable中仍存在旧行？ #

核心原因和TWCS的压缩机制+TTL tombstone的时间戳特性有关：

• 你使用的TWCS是按时间窗口划分SSTable的，每个窗口的SSTable只存储对应时间范围内写入的数据。但当旧窗口SSTable里的行TTL到期时，Cassandra会生成对应的tombstone来标记数据失效。
• 在TWCS的压缩过程中，这些从旧行生成的tombstone会被合并到当前活跃的时间窗口SSTable中，但这些tombstone的时间戳是继承原行的写入时间戳（而非生成tombstone的时间）。
• 这就导致新的SSTable中包含了旧时间戳的tombstone，拉低了它的最小时间戳；而旧SSTable的最大时间戳又高于这个值，Cassandra就会认为旧SSTable中可能存在未被新SSTable覆盖的数据，因此不会触发驱逐逻辑。

2. 当前情况下，强制驱逐旧SSTable的简便方法 #

以下是几种可行的方案，按推荐优先级排序：

方案一：使用sstablescrub工具清理 #

这是最安全的方式，它会重新处理目标列族的SSTable，彻底清理掉已被tombstone完全覆盖的数据，同时修正SSTable的min/max时间戳元数据：

nodetool sstablescrub <keyspace_name> <column_family_name>

• 注意：该操作会占用一定的IO和CPU资源，建议在业务低峰期执行；如果集群节点较多，可以逐节点运行避免影响整体性能。

方案二：手动触发全量压缩（Major Compaction） #

虽然TWCS默认不推荐全量压缩，但针对当前场景，它可以将所有SSTable合并为一个，旧SSTable会被自动标记为删除：

nodetool compact <keyspace_name> <column_family_name>

• 注意：全量压缩的资源消耗较高，如果你的数据量较大，可能会导致短时间的性能下降，需谨慎选择。

方案三：手动移除旧SSTable（风险较高，需确认数据已完全失效） #

因为你已经通过Java程序确认旧SSTable完全被tombstone覆盖，可以手动处理：

1. 先停止目标节点的Cassandra服务（或用nodetool drain将节点安全下线）
2. 找到旧SSTable的存储路径（默认在/var/lib/cassandra/data/<keyspace>/<cf>下），将其移到单独的备份目录
3. 重启Cassandra服务，执行nodetool refresh <keyspace_name> <column_family_name>
4. 确认集群数据正常后，再删除备份的旧SSTable

• 注意：此方法有数据丢失风险，务必确保旧SSTable无有效数据，且操作前做好全量备份。

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