Cassandra 磁盘空间利用率高答案

【问题标题】：Cassandra high disk space utilizationCassandra 磁盘空间利用率高
【发布时间】：2021-10-24 00:12:14
【问题描述】：

我们在生产中有一个 12 节点的 cassandra 集群。最近，几乎所有节点都在使用高于 85% 的磁盘空间。我们尝试为几个表添加 default_time_to_live、gc_grace_seconds。但似乎对记录数或磁盘空间没有影响。有执行 nodetool 压缩和清理的建议。但这也提到不建议在生产环境中运行。

一些具体问题，

尝试将 TTL 设置为 100 天，将 gc 设置为 3 小时。预计超过 90 天的记录应在 3 小时后删除。但它仍然完好无损。使用 TTL 设置删除超过 100 天的记录时，还有什么需要注意的吗？预计也将释放磁盘空间。同样，在删除记录后还应该做些什么来释放磁盘空间。

ALTER TABLE my_keyspace.my_item WITH default_time_to_live=8640000
ALTER TABLE my_keyspace.my_item WITH gc_grace_seconds=10800

是否可以在所有实例的磁盘空间利用率超过 85% 的 prod 环境中运行 nodetool compact，然后执行 nodetool cleanup？

请分享其他建议以释放 Cassandra 使用的磁盘空间。

Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.1.x.x  997.26 GiB  256          24.7%             erff8abf-16a1-4a72-b63e-5c4rg2c8d003  rack1
UN  10.2.x.x   1.22 TiB   256          26.1%             a8auuj76-f635-450f-a2fd-7sdfg0ss713e  rack1
UN  10.3.x.x   1.21 TiB   256          25.4%             8ebas25c-4c0b-4be9-81e3-013fasdas255  rack1
UN  10.4.x.x   1.27 TiB   256          25.1%             wwwdba15-16f3-41a8-b3d1-2d2b6e35715d  rack1
UN  10.5.x.x  975.67 GiB  256          24.7%             72ed4df7-fb65-4332-b8ac-e7461699f633  rack1
UN  10.6.x.x  1.01 TiB   256          24.8%             39803f58-127f-453b-b102-ed7bdfb8afb2  rack1
UN  10.7.x.x  1.18 TiB   256          25.9%             b6e692a6-249f-433d-8b54-1d20d4bc4962  rack1
UN  10.8.x.x  1.12 TiB   256          24.5%             8ed8c306-9ac9-4130-bff1-97f7d5d9a02f  rack1
UN  10.9.x.x  973.26 GiB  256          24.4%             f7489923-3cc3-43ec-83ca-42bbdeb0cbb7  rack1
UN  10.10.x.x  1.13 TiB   256          26.0%             ea694224-ds0b-42f5-9acf-ff4ddfb450e0  rack1
UN  10.11.x.x   1.22 TiB   256          24.0%            ddde4bce-553e-4246-9920-47sdfdf324ed  rack1
UN  10.12.x.x  1.28 TiB   256          24.4%             0222d40f-edb8-4710-9bae-39dsfd87e18db  rack1

【问题讨论】：

标签： cassandra

【解决方案1】：

在表上设置默认 TTL 仅适用于新插入的数据。如果你还记得，SSTables 在 Cassandra 中是不可变的——一旦它们被写入磁盘，它们就不会被更新/修改。这意味着 SSTable 中的任何现有数据不会应用新的 TTL，因此不会释放任何磁盘空间。
由于 (1) - SSTables 中的现有数据不会过期，因此不会产生影响。默认 TTL 仅适用于新的突变/写入（插入/更新）。出于同样的原因，运行nodetool cleanup 也不会产生影响，因为没有什么需要清理的。无论如何，正如我在这篇文章中所解释的那样，在 C* 中，主要的压缩是一个坏主意 -- https://community.datastax.com/questions/6396/。

那么您如何处理现有节点上的磁盘空间不足的问题？您需要通过添加更多节点来增加集群的容量。当您逐个添加节点时，您可以在现有节点上运行nodetool cleanup 以立即释放空间。

我根据所有 12 个节点的平均节点密度 1153GB 做了一些粗略的计算。如果添加 1 个节点，每个节点平均可以释放约 89GB。如果添加 2 个节点，它应该平均每个节点释放约 165GB。 3 个节点大约下降 231GB，4 个节点大约 288GB。干杯！

【讨论】：

我同意添加节点可能是最好的方法。在 85% 满时，压缩可能没有足够的空间来完成。
谢谢。请建议仅添加额外的节点是否有帮助或增加现有实例的磁盘空间也可以。我们已经有 12 个节点，我们不希望最终有更多节点需要管理！
我也在寻找一个长期的解决方案来控制 cassandra 实例空间。我可以理解添加额外节点的建议是因为集群的状态无法控制。但是我如何确保我不会陷入同样的境地！
我还想确保自动清理超过 100 天的记录。如果今天设置的 TTL 将在 100 天后才开始生效，我该如何清除比这更早的记录。是否会手动删除记录，然后启用较小的 gc_grace_seconds（比如至少 3 小时），确保删除记录和墓碑？
也发布在community.datastax.com/questions/12155/…上

【解决方案2】：

删除数据并不意味着它会立即物理消失。这是基线(deletion time + gc_grace_seconds)，之后可以通过压缩过程删除数据。直到在预期的表上没有发生压缩，您的磁盘上才会有数据。回到您减少磁盘空间的问题。您可以尝试任何适合您情况的选项。

Run nodetool compact。明智地使用此选项。由于压缩本身需要空间，因此确定可以在不因磁盘空间不足而杀死节点的情况下压缩的键空间表。如果你的桌子上有 STCS，也可以使用 -s 选项。
将unchecked_tombstone_compaction 设置为真。这解决了很多问题。如果你有很多墓碑，那么这将触发单表压缩。
使用用户定义的压缩在选定的 sstables 上运行压缩。
如果您的应用程序允许，您可以截断包含大量无用数据的表并使用所需数据重新填充表。

您可以参考 Alain Rodriguez 的 blog 以了解墓碑以及如何清理。

注意：首先在您的测试环境中应用任何程序测试之前。

【讨论】：

我在 pre prod 环境下进行了测试，我发现 nodetool compact 确实为我们清理了磁盘空间。我还注意到磁盘空间从 73% 上升到 87%（压缩期间），然后减少到 60%（压缩完成后）。我会在 Prod 中尝试 -s 选项。
在 prod 上彻底运行之前测试您的程序。理论和实践是两种不同的野兽。
@Radhika 手动运行压缩应该是最后的选择。完成此操作后，您将需要永久手动运行它，因为生成的 SSTable 文件大小将大大降低将来有机运行的修复机会。
@Radhika 看到 Erick 的回答。我认为在这里添加另一个节点是您的最佳选择。
正如@Erick 在他的回答中提到的那样，压缩对您的情况没有任何帮助，因为您之前没有设置 ttl，所以目前最好的选择是添加节点。将来，您可以将 ttl 添加到您的数据中，这将允许数据缓慢移出。同样对于旧数据，您可以考虑重新填充所需数据并截断旧数据。