Cassandra的墓碑太多了

svmlkihl  于 2021-06-14  发布在  Cassandra
关注(0)|答案(3)|浏览(446)

我有一个名为'holder'的表,它有一个分区,每一小时我们将有60k个条目,
我还有一个名为'holderhistory'的表,它的分区ID是'date',因此'holder'表中的每天记录都会复制到'holderhistory'
应用程序中将运行一个作业
i) 它收集holder表中的所有旧条目并复制到holderhistory表
ii)从holder表中删除旧条目
现在的问题是-holder表中创建的墓碑太多了。
默认情况下,逻辑删除将在10天(864000秒)gc\u grace\u秒后清除
但我不想把墓碑保留超过3个小时,
1) 所以最好把gc\u grace\u seconds设置为3小时?
2) 或者最好将默认的\u time \u to \u live设置为3小时?
删除墓碑的最佳解决方案是什么?
另外,将gc\u grace\u秒从10天减少到3小时的后果是什么?我们将在哪里产生影响?
感谢您的帮助。

5ktev3wc

5ktev3wc1#

如果您将gcgraceseconds参数减得太低,并且任何节点的恢复时间都长于gcgraceseconds,在这种情况下,一旦这些节点中的一个恢复联机,它就会错误地认为接收到删除的所有节点实际上都错过了一次写入,并且它将开始修复所有其他节点。我建议你用默认的时间来生活并尝试一下。

j2qf4p5b

j2qf4p5b2#

回答您的特殊情况:由于表'holder'只包含一个分区,您可以使用一个“deletebyspartitionkey”语句删除整个分区,从而有效地创建一个墓碑。
如果你每天删除一次分区,你将每天得到一个墓碑。。。这是可以接受的。
1) 与 gc_grace_seconds 等于3小时,如果rf>1,则不能保证从超过3小时的节点故障中持续恢复
2) 与 default_time_to_live 等于3小时,每个记录将在插入3小时后创建一个墓碑删除
因此,您可以将默认gc\u grace\u seconds设置为10天,并注意删除您的每日记录,例如 DELETE FROM table WHERE PartitionKey = X 编辑:回答你关于暗示移交的评论。。。
比如说 RF = 3 , gc_grace_second = 3h 一个节点掉了。另外两个副本继续接收突变(insert、update、delete),但它们无法将它们复制到脱机节点。在这种情况下,提示将临时存储在磁盘上,如果死节点返回,则稍后再发送。
但一个提示在 gc_grace_seconds 之后,它将永远不会被发送。
现在,如果删除一行,它将在2个副本的sstables中生成一个tombstone,并在协调器节点中生成一个提示。3小时后,压缩管理器将删除联机节点中的逻辑删除标记,提示将过期。
稍后,当您的死节点返回时,它仍保留该行,并且它无法知道该行已被删除,因为复制副本上不存在任何提示和墓碑。。。因此,这是一个僵尸行。

s71maibg

s71maibg3#

您可能还会发现这篇支持博客文章很有用:
https://academy.datastax.com/support-blog/cleaning-tombstones-datastax-dse-and-apache-cassandra

相关问题