如果表被删除，SSTables 永远不会在磁盘上删除答案

【问题标题】：SSTables are never deleted on disk if table gets dropped如果表被删除，SSTables 永远不会在磁盘上删除
【发布时间】：2016-12-27 18:21:38
【问题描述】：

如果表被删除，SSTables 永远不会在磁盘上被删除。

我有一个表，其墓碑数 >100000，因此我的读取查询引发了墓碑错误。然后我删除了表，但这并没有删除 SSTable 文件。我重新创建了表，然后我运行了我的选择查询，我再次看到了墓碑错误。我不明白为什么旧的墓碑错误又出现了？另外，SSTable 什么时候会在磁盘上被删除？

【问题讨论】：

标签： cassandra tombstone

【解决方案1】：

截断表不会删除磁盘上的 SSTable。你需要运行nodetool cleanup

Tombstone 将通过压缩消失，但只有在 gc_grace_seconds 过去后才会消失。默认值为 10 天。为什么这么长？它被设计为比一周长一点，提供足够的时间在删除删除之前在集群上运行修复。这最大限度地提高了节点间一致性的机会。

【讨论】：

我做了“drop table xyz”，并且相应的 sstables 没有从磁盘中删除。我也运行 nodetool cleanup，但没有帮助。
xmas79 是正确的，Cassandra 将快照数据，从而创建硬链接。使用“nodetool clearsnapshot”删除所有快照或您截断的特定表的快照。在 Linux 中，“ls -l”会告诉你一个文件有多少硬链接。
我看到 sstables 的文件夹永远不会被删除，即使里面的所有文件（数据库、索引等）都被删除了。并且没有快照存在。知道为什么会这样吗？

【解决方案2】：

截断操作比删除和重新创建更安全。 truncate 可能会抛出超时异常，请再做一次，直到完全完成为止。

【讨论】：

【解决方案3】：

为了从磁盘中删除您的表，您需要确保当前没有硬链接指向它们。默认情况下，DROP 命令将创建 CF 的快照。您需要在 YAML 文件中将 auto_snapshot 属性设置为 false：

# Whether or not a snapshot is taken of the data before keyspace truncation
# or dropping of column families. The STRONGLY advised default of true 
# should be used to provide data safety. If you set this flag to false, you will
# lose data on truncation or drop.
auto_snapshot: false

如果您希望在安全方面犯错（以及重新创建密钥空间的一般过程），您可以选择：

如果 mytable 存在则删除表
创建表 mytable (....)
截断我的表

到目前为止，我从未遇到过任何问题。

【讨论】：

我做了 auto_snapshot: false 并重新启动了 Cassandra。此外，如你所说，删除并重新创建了一个表。在删除或截断表时，SStable 文件仍然存在于磁盘上，如果您转到 Cassandra 的数据目录并进行验证。我想知道，为什么表的 SStable 文件仍然保留在磁盘上并且没有被删除？