在 Cassandra 节点上增加磁盘大小时要考虑什么？答案

【问题标题】：What's to think of when increasing disk size on Cassandra nodes?在 Cassandra 节点上增加磁盘大小时要考虑什么？
【发布时间】：2023-03-30 00:33:01
【问题描述】：

我在生产环境中运行一个 10 节点 Cassandra 集群。 99% 写入； 1% 读取，0% 删除。节点有 32 GB RAM； C* 使用 8 GB 堆运行。每个节点都有一个用于提交日志的 SDD 和一个用于数据（sstables）的 2x4 TB 旋转磁盘。架构仅使用密钥缓存。 C* 版本是 2.1.2。

可以预见，集群的可用磁盘空间很快就会用完。所以它的存储容量需要增加。客户端更喜欢增加磁盘大小而不是添加更多节点。因此，一个计划是在每个节点中使用 2x4 TB 的旋转磁盘，并用 3x6 TB 的旋转磁盘替换。

这里有什么明显的陷阱/警告需要注意吗？喜欢：
- C* 能否在如此大的 RAM 下为每个节点处理多达 18 TB 的数据？
- 是否可以通过挂载一个新的（更大的）磁盘来增加磁盘大小，将所有 SS 表复制到该磁盘，然后将其挂载到与原始（较小）磁盘相同的挂载点（以替换它）？

【问题讨论】：

您也许不必移动数据。在cassandra.yaml 中，参数data_file_directories 可以有多个值。

标签： cassandra

【解决方案1】：

我建议添加节点而不是增加当前节点的数据大小。添加节点将利用 Cassandra 的分布特性，即拥有易于更换的小型节点。

此外，对于旋转磁盘，集群中单个节点的推荐大小约为 1 TB。一旦你达到更高的水平，我只能想象性能会显着下降。

更不用说如果一个节点丢失了它的数据，恢复它需要很长时间，因为它必须从其他节点流式传输大量数据。

C* 能否在如此大的 RAM 下为每个节点处理高达 18 TB 的数据大小？

这在很大程度上取决于您的工作量。

是否可以通过挂载一个新的（更大的）磁盘来增加磁盘大小，将所有 SS 表复制到其中，然后将其挂载到与原始（较小）磁盘相同的挂载点上（以替换它）？

我看不出它不起作用的原因。

【讨论】：

感谢您的建议。鉴于 OP，我将尝试为现有节点配备更大的磁盘。如果这被证明是个坏主意；我将在要添加的新节点中使用旧磁盘。但由于我的读取量很少，性能可能还可以接受。

【解决方案2】：

这是 Cassandra 中的反模式。分布式数据库是 Cassandra 的关键特性

【讨论】：