用新节点替换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无法立即删除数据。它必须首先写入新数据，称为逻辑删除，然后在允许在下一次压缩中清除逻辑删除之前等待gc_grace_seconds。你没有谈到过的事情是通过gc_grace_seconds对你的墓碑的影响进行推理。如果您的墓碑不够大，无法清除，那么节点替换和压缩都不会帮助您，直到gc_grace_seconds已经过去（或者您在此维护期间暂时降低gc_grace_seconds，但如果遇到这种情况，则存在在某些情况下意外恢复数据的风险维护期间节点中断）。
• 如果您已经整理了gc_grace_seconds与tombstone age，则手动压缩将恢复您的磁盘空间。如果你正在使用大小分层压缩，它也会将你的所有数据压缩成一个单独的sstable ......然后很长一段时间不会再次压缩...导致更多的空间恢复问题如果您更新/删除数据。
• 切换到水平压缩可以帮助解决空间恢复问题。它使用更小的sstables并保证旧更新或可回收的墓碑不会占用超过一定百分比的空间。然而，如果在写入容量方面运行群集“热”，则磁盘压缩对磁盘的要求更高，切换可能会影响性能。
• 我认为节点替换也是回收磁盘的可行策略，但是我不记得流媒体的所有细节，以确定它是否会拉过陈旧的墓碑或先压缩它们......我认为它先压缩。不过，您可能希望首先在测试台上进行验证。