将gc\u grace\u秒更改为10到0天后对cassandra进行主要压缩

kmbjn2e3  于 2021-06-14  发布在  Cassandra
关注(0)|答案(2)|浏览(377)

我有一个cassandra集群,它有gc\u grace\u秒10天。自动压缩已启用,并按配置运行,但我怀疑自动压缩没有清除过期的gc\u grace\u秒持续时间(10天)的逻辑删除。我计划对那张table进行一次大的压缩,所以我的问题是。
1) 我应该在不改变gc\u grace\u seconds的情况下运行主要压缩10天吗?
2) 我应该在0天内运行主要的gc\u grace\u seconds吗?
3) 如果我将gc\u grace\u seconds更改为0,那么它是否也适用于将来的数据或已经存在的具有gc\u grace\u seconds天数的数据?
提前谢谢。

agyaoht7

agyaoht71#

1) 我应该在不改变gc\u grace\u seconds的情况下运行主要压缩10天吗?
对。如果设置为0,则逻辑删除将不会传播到群集中的其他节点。导致数据不一致。
3) 如果我将gc\u grace\u seconds更改为0,那么它是否也适用于将来的数据或已经存在的具有gc\u grace\u seconds天数的数据?
如果您更改gc\u grace\u seconds,它将适用于未来数据以及当前数据。
如果你想通过压缩来清除墓碑,我有两个选择给你

  1. nodetool compact -s keyspace table 这将压缩表并创建50%-25%-12.5%的sstables,以此类推
  2. nodetool compact --user-defined path/to/sstable 这将清除上面提到的sstable中的墓碑。
muk1a3rh

muk1a3rh2#

首先,您不应该将gc\u grace\u seconds设置为0,除非在单节点集群上。如果将gc\u grace\u seconds设置为某个时段,则必须在每个这样的时段中至少运行一次修复,否则会有数据恢复的风险—当群集上的一个节点错过了删除,而其他节点删除了它们的逻辑删除时,就会发生这种情况,因此以后的修复会认为数据是新的,而不会意识到它已经被删除。如果您曾经将gc\u grace\u seconds设置为0,那么您以前删除的任何数据都可能会在下次修复时恢复,前提是这些数据恰好位于其中一个副本上(因为此特定副本由于某些临时问题而错过了删除)。
因此,正确的方法是用10天的原始gc\u grace\u秒进行一次主要压实(并且确保至少每10天进行一次修复)。
但您需要考虑为什么要运行一个大型压缩。轻微的压缩是否能去除旧的(过去10天的)墓碑取决于很多因素,比如你最近是否对这些墓碑所在的同一个分区做了其他修改。但是,除非墓碑给您带来了严重的问题(大量的磁盘空间、较慢的读取速度等),否则进行大规模压缩可能是不值得的。主要压缩不是免费的,而且(至少在大小分层压缩策略中)压缩之后,所有数据都放在一个文件中,并且需要更长的时间才能再次压缩。

相关问题