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

时间:2017-04-10 10:02:19

标签: amazon-ec2 cassandra cassandra-2.1 nosql

我正面临Cassandra的磁盘空间问题。其中一个密钥空间占用了近25 GB的空间。由于这张表包含大量数据,我开始清理表格和1亿条记录,我清理了9800万条记录。尽管有数据清理,但cassandra仍需要25 GB的空间。

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

  1. 将第6个节点添加到现有集群并关闭现有节点的1(让第一个节点称为第一个节点)(这里我预计第一个节点的数据将被复制到新添加的节点,因为复制因子已设置为3,其中一个副本已经关闭)
  2. 一段时间后(考虑到将数据复制到新的cassandra节点需要一些时间),对接下来的4个新节点重复上述步骤(因此我的集群将包含新的Cassandra 5节点,其中包含从旧cassandra节点复制的数据)
  3. 这是解决我问题的正确方法吗?如果这不起作用或不是一个好的解决方案,我想了解原因和任何其他安全的替代方法。

    注意:我使用的是Cassandra 2.1.14

1 个答案:

答案 0 :(得分:0)

你没有提供足够的信息来真正知道发生了什么,但有些事情要考虑......

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