为什么我的 cassandra 集群的某些节点的大小稳步增长？答案

【问题标题】：why are certain nodes of my cassandra cluster steadily growing in size?为什么我的 cassandra 集群的某些节点的大小稳步增长？
【发布时间】：2019-04-30 23:03:49
【问题描述】：

我有一个 48 节点 C* 集群 (3.11.4)，分布在 4 个 AWS 区域，RF=3。几个月前，我开始注意到一些节点上的磁盘使用量持续增加。起初我通过销毁节点并重建它们来解决问题，但问题又回来了。

我最近做了一些调查，这就是我发现的：
- 通过简单地查看磁盘空间使用情况，我将问题缩小到使用 TWCS 的 CF（并且所有写入的行都有一个 ttl）
- 在每个区域中，有 3 个节点存在磁盘空间增长的问题（匹配复制因子）
- 在每个节点上，我使用sstableexpiredblockers 将问题追踪到特定的 SSTable。这个 SSTable 正在阻止所有其他 SSTable 被清理
- 在 SSTable 中，使用 sstabledump，我发现一行没有 ttl 像其他行一样，并且似乎来自团队中的其他人测试某些东西并忘记包含 ttl
- 除了这一行，所有其他行都显示“过期：真”，因此我怀疑
- 当我查询该特定分区键时，我没有得到任何结果
- 无论如何我都尝试删除该行，但这似乎并没有改变任何东西
- 我也试过nodetool scrub，但也没有用

这个没有 ttl 的流氓行能解释问题吗？如果是这样，为什么？如果没有，是否有人有其他想法？为什么行在sstabledump 中显示，但在我查询时却没有？

感谢任何帮助或建议！

【问题讨论】：

标签： cassandra

【解决方案1】：

一个可能的原因是您的架构的定义，更准确地说是分区键，因为您可能有大部分记录分配给少数令牌，这种情况称为“热点”。

例如，假设您的表有汽车的信息，而您的分区令牌是它所在的国家/地区，则分配用于保存来自美国或德国的汽车数据的节点将具有更大的数据量compared to the ones that have the tokens for cars in Bangladesh or Pakistan

您可能希望使用复合分区键，以实现数据分片的均匀分布。

【讨论】：

热点无法解释为什么数据继续增长，因为所写的所有内容都有一个 ttl（我试图在问题中更清楚地说明这一点，ttl 约为 1 天）。这是由热点引起的，这意味着为给定的分区键写入的数据越来越多，在这种情况下，日志中会出现大量“大分区”警告。它也无法解释 sstableexpiredblockers 问题表明一个特定的 SSTable 正在阻止其他 SSTable 删除
很抱歉不同意，但我们正在谈论不同的话题。 TTL 指的是数据在集群中保存的时间，而不是它在集群中的分布方式，分区键也是如此。另请注意，设置 TTL 不会降低磁盘利用率，因为首先您需要等待 gr_grace_seconds 时间段，然后才能通过压缩删除数据。默认为 10 天
gc_grace_seconds 设置为 0。我明白你在说什么，但我的意思是，即使所有数据都写入同一个分区，如果所有数据都具有相同的 ttl，那么您会期望数据大小保持不变，而不是随着时间的推移继续增长（除非写入的数据速率一直在增加）。我错过了什么吗？
将 gc_grace_seconds 设置为零会禁用集群上的提示切换，这会降低集群对硬件故障的弹性thelastpickle.com/blog/2018/03/21/…

【解决方案2】：

我能够通过对 CF 执行主要压缩来解决问题。

这是我对为什么会这样的理解：

TWCS 将数据存储在时间窗口中，当 sstable 中的所有数据都过期时，它将删除整个文件。 TWCS 不会在不同的时间窗口压缩 sstables
在没有 ttl 的情况下写入数据意味着您不能删除 sstable，因为它有一些未过期的数据。即使删除它也不够，因为删除该行只会在另一个 sstable 中创建一个墓碑
出于性能原因，cassandra 只会自动执行次要压缩，这意味着在这种情况下它永远无法压缩死数据

【讨论】：