Question

我有一个Cassandra群集（2个DC），每个6个节点，RF2。每个节点中的4个节点（每个DC）已满，所以我需要尽快清理空间。

我试图进行一次全面维修，但是由于空间开始增加甚至更多，维修工作最终中止了，因此最终导致一个坏主意。作为最后的解决方案，我正在考虑开始修复，然后从最小到最大清理特定的列。

即

nodetool repair -full foo_keyspace bar_columnfamily

nodetool cleanup foo_keyspace bar_columnfamily

您认为此过程对数据安全吗？

谢谢

Answer 1

您在问题中提出的命令有几个错误的假设。首先，“修复”不应也不会节省任何空间。修复所做的所有工作是查找不同副本之间的不一致之处并修复它们。它不会做任何事情（如果没有不一致的地方），或者是 add 数据，而不是删除数据。其次，在将新节点添加到群集之后，您需要执行“清除”操作-在每个节点将其一些数据发送到新节点之后，“清除”将从旧节点中删除数据。但是，在不添加节点时清除并不重要。

您可能要查找的命令是“ compact”。这样可以节省空间，但前提是您知道自己有很多覆盖（重写现有行），删除或数据过期（TTL）。您正在使用哪种压缩策略？如果这是默认的，按大小分层的压缩策略（STCS），则可以开始进行大型压缩（nodetool compact），但应注意其中涉及的巨大风险：

重大压缩将所有数据合并为一个sstable（Cassandra的磁盘文件格式），删除已删除，过期或覆盖的数据。但是，在此压缩过程中，您会同时拥有两者输入和输出文件，在最坏的情况下，这可能会使磁盘使用率翻倍，并且如果磁盘已满50％，则可能会失败。这就是为什么许多Cassandra最佳实践指南建议不要填满磁盘的50％以上。但这只是最坏的情况。如果您知道输出文件将比输入文件小得多（因为大多数数据已被删除），则可以减少可用空间。也许更有用，如果您有许多单独的表（列族），则可以分别压缩每个表（按照您的建议，从最小到最大），并且压缩期间临时需要的最大磁盘空间量可能少于50％磁盘。

Scylla是Cassandra的C ++重新实现，正在开发一种称为“混合压缩”（参见https://www.slideshare.net/ScyllaDB/scylla-summit-2017-how-to-ruin-your-performance-by-choosing-the-wrong-compaction-strategy）的方法，类似于Cassandra的大小分层压缩，但是将其压缩成小块而不是生成一个大文件，以便避免在压缩过程中占用大量临时磁盘。不幸的是，Cassandra还没有此功能。

Answer 2

一个好主意是首先在最小键空间上的最小表上开始修复，然后进行完全修复。这将花费时间，但方法更安全，并且没有机会挂起和交通损失。维修完成后，以与维修相同的方式开始清理。这样对节点和群集也没有影响。

Answer 3

磁盘的填充空间不应超过50％到60％。如果超出磁盘使用量，则需要考虑增加磁盘或添加更多节点。

通常最好遵循Datastax建议：https://docs.datastax.com/en/dse-planning/doc/planning/planPlanningDiskCapacity.html

几乎满载的Cassandra节点中的清理空间

3 个答案: