关于nodetool garbagecollect多数据文件夹工作机制及跨文件夹清理的问询

1. 多数据文件夹下nodetool garbagecollect的工作原理 #

Cassandra的多数据文件夹是同一节点下的不同存储路径，节点会将SSTable分散存储在这些路径中，但所有文件夹属于同一节点的同一keyspace/table，数据逻辑上是统一的。nodetool garbagecollect（简称GC）的核心是清理过期数据和冗余的shadowed数据，工作流程如下：

• 触发GC后，节点会遍历目标表所有data文件夹中的SSTable，对每个SSTable单独做逻辑扫描。
• 对每个SSTable，GC会标记三类可清理数据：超过TTL的过期数据、过了gc_grace_seconds窗口期的tombstone、被后续写入覆盖的shadowed data。
• 之后生成仅包含有效数据的新SSTable，替换旧SSTable。新SSTable会自动存入剩余空间较多的data文件夹。
• 整个过程逐SSTable处理，但会跨所有data文件夹做全局数据有效性判断——因为shadowed data的判定依赖全表最新写入记录，不管这些记录存在哪个文件夹的SSTable里。

2. data1文件夹SSTable存在tombstone时，清理data0中shadowed data的逻辑 #

shadowed data指被后续写入（包括tombstone）完全覆盖或标记删除的旧数据，比如data0里的user:123, name:Alice，被data1中同一行的tombstone或新值覆盖，就属于shadowed data。GC的处理逻辑如下：

• GC启动后，先加载目标表所有SSTable的元数据（含data0和data1），构建全表的最新数据视图。
• 扫描data0的SSTable时，对比全局视图：如果某条数据对应的行在data1的SSTable里有tombstone，且该tombstone已过gc_grace_seconds，或者tombstone虽未过期但这条数据已被完全覆盖，那么这条数据会被标记为可清理的shadowed data。
• 生成data0的新SSTable时，这些标记条目会被排除，只保留有效数据。
• 注意：若tombstone仍在gc_grace_seconds窗口期内，GC不会清理对应的shadowed data——这是为了保障集群副本同步，避免节点离线导致数据不一致，只有tombstone过期后，旧数据才会被彻底清理。

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