Cassandra 磁盘空间利用率高

Question

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

一些具体问题，

1. 尝试将 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

2. 是否可以在所有实例使用超过 85% 的磁盘空间的生产环境中运行 nodetool compact 然后进行 nodetool 清理？

请分享其他建议，以释放 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

Answer 1

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

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

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