用新节点替换 cassandra 集群中的现有节点

Question

我面临 Cassandra 的磁盘空间问题。其中一个键空间占用了将近 25 GB 的空间。由于这张表包含大量数据，我开始清理表，在 1 亿条记录中，我清理了 9800 万条记录。尽管进行了数据清理，cassandra 仍然占用 25 GB 空间。

为了确保 cassandra 仅占用剩余 200 万条记录的磁盘空间，我正在尝试实施以下方法（我有 5 个 cassandra 节点集群，所有键空间的复制因子设置为 3）：

1. 将第 6 个节点添加到现有集群并关闭现有节点的 1 个（假设是第一个节点）（这里我期望第一个节点的数据将复制到新添加的节点，因为复制因子设置为 3 和其中之一此副本已关闭）
2. 一段时间后（考虑到将数据复制到新的 cassandra 节点需要一些时间），为接下来的 4 个新节点重复上述步骤（因此我的集群将包含新的 Cassandra 5 节点，其中数据从旧 cassandra 节点复制）李>

这是解决我的问题的正确方法吗？如果这不起作用或不是一个好的解决方案，我想了解原因以及任何安全的替代方法。

注意：我使用的是 Cassandra 2.1.14

Answer 1

您没有提供足够的信息来真正了解正在发生的事情，但有些事情需要考虑......

• 为了在失败时提供最终的一致性，Cassandra 不能立即删除数据。它必须首先写入新数据，称为 tombstone，然后等待 gc_grace_seconds，然后才能在下一次压缩中清除 tombstone。您还没有谈到做的是通过 gc_grace_seconds 对您的墓碑的影响进行推理。如果您的墓碑不够老而无法清除，那么在 gc_grace_seconds 过去之前，节点替换和压缩都不会帮助您（或者您在此维护期间暂时降低 gc_grace_seconds，但是在某些情况下，如果您遇到意外恢复数据的风险维护期间节点中断）。
• 如果您已经整理出 gc_grace_seconds 与墓碑年龄，手动压缩将恢复您的磁盘空间。如果您使用的是 size-tiered-compaction，它还会将您的所有数据压缩到一个单一的 sstable 中......然后可能在很长一段时间内不会再次压缩......如果出现更多空间恢复问题您更新/删除您的数据。
• 切换到分级压缩有助于解决空间恢复问题。它使用更多更小的 sstables 并保证不超过一定百分比的空间将被旧更新或可回收的墓碑占用。分级压缩对磁盘的要求更高，但是，如果您在写入容量方面“热”运行集群，则切换可能会影响性能。
• 我认为节点替换也是回收磁盘的一种可行策略，但我不记得流式传输的所有细节以确定它是否会拉过陈旧的墓碑或先压缩它们......我认为首先压缩。不过，您可能想先在测试台上进行验证。