我有一个48节点的c*集群（3.11.4），分布在4个aws区域，rf=3。几个月前，我开始注意到一些节点上的磁盘使用率一直在增加。起初，我通过销毁节点并重建它们来解决问题，但问题又回来了。
我最近又做了一些调查，我发现：
-通过简单地查看磁盘空间使用情况，我将问题缩小到使用twcs（并且所有写入的行都有ttl）的cf
-在每个区域中，有3个节点存在磁盘空间增长的问题（与复制因子匹配）
-在每个节点上，我使用 sstableexpiredblockers . 这个sstable正在阻止所有其他sstable被清理
-在sstable中，使用 sstabledump ，我发现一行没有像其他行那样的ttl，似乎是团队中其他人在测试某个东西时忘记包含ttl
-除此之外，所有其他行都显示“expired:true”，因此我怀疑
-当我查询特定的分区键时，没有得到任何结果
-我试图删除行，但似乎没有任何改变
-我也试过了 nodetool scrub ，但这也无济于事
这个没有ttl的流氓行能解释这个问题吗？如果是，为什么？如果没有，还有人有其他想法吗？为什么排成一排 sstabledump 但我问的时候不是吗？
感谢您的帮助和建议！
2条答案
按热度按时间zzzyeukh1#
我能够通过对cf执行主要压缩来解决问题。
以下是我对为什么这样做的理解：
twcs在时间窗口中存储数据，当sstable中的所有数据都过期时，它将删除整个文件。twcs不会在不同的时间窗口中压缩sstable
在没有ttl的情况下写入数据意味着不能删除sstable，因为它有一些未过期的数据。即使删除它也不够，因为删除该行只会在另一个sstable中创建一个tombstone
由于性能原因，cassandra只会自动执行较小的压缩，因此这意味着在这种情况下它永远无法压缩掉死数据
fnvucqvd2#
一个可能的原因是模式的定义，更准确地说是分区键，因为您可能有很大一部分记录分配给了几个令牌，这种情况称为“热点”。
例如，假设您的表中有汽车的信息，并且您的分区令牌是它所在的国家/地区，分配用于保存来自美国或德国汽车数据的节点的数据量将比在孟加拉国或巴基斯坦有汽车令牌的节点的数据量更大
您可能希望使用复合分区密钥，以使数据碎片分布均匀。