Cassandra DB 缓慢消耗磁盘答案

【问题标题】：Cassandra DB slowly consuming the diskCassandra DB 缓慢消耗磁盘
【发布时间】：2014-04-29 10:38:34
【问题描述】：

我有一个 Cassandra 数据库，用于持久化最后一小时的稳定消息流。每行的 TTL 设置为 1 小时。查询数据库确认旧记录已消失，但磁盘利用率不断上升。它有时会下降一点（我假设是由于压缩），但大约一周的总体趋势是磁盘使用量不断增加，直到磁盘已满，此时它停止接受数据。

杀死进程并重新启动会稍微清理一下，但它会在大约 8-9G 的实际数据上以大约 60G 的磁盘利用率开始。

试图运行./nodetool compact 只是挂在那里。

磁盘消耗从何而来？

【问题讨论】：

你确定 nodetool compact “只是挂起”吗？运行可能需要很长时间。您应该通过在不同的控制台中运行 nodetool compactionstats 并在 cassandra 的系统日志中看到压缩日志消息来查看进度。完成后，您可能会看到已用磁盘空间大幅下降
您多久进行一次维修？
@Gryphius 我会试一试，但我已经把它放在那里大约半个小时了，它还没有回来。

标签： cassandra

【解决方案1】：

TTL 并不意味着您的数据会从磁盘中消失。它实际上做了什么，它创建了一个墓碑，表明该记录已被删除。这个墓碑必须保留，以防另一个节点没有收到删除命令或遭受网络分区。直到 GC_GRACE 秒过期（默认为 10 天），墓碑才会被删除。这意味着您的数据将一直存在，直到到期为止。出现这种延迟是为了让您有时间在最终移除墓碑之前执行修复，以防止死数据从副本中复活。

http://wiki.apache.org/cassandra/DistributedDeletes

【讨论】：

事情就更复杂了issues.apache.org/jira/browse/CASSANDRA-6654
这个故事的寓意：在最终一致的系统中删除是困难的。
@RussS 是的。就是这样。谢谢！我实际上阅读了该页面，但显然没有注意最后一段。一旦我做了ALTER TABLE messages WITH gc_grace_seconds = 0; 磁盘使用率下降到我的预期。