我有一个名为“ holder ”的表，该表具有单个分区，其中每隔一小时我们将有60K条目，
我还有一个名为“ holderhistory ”的表，该表具有“ 日期”作为partitionId，因此“ holder”表中的每一天记录都将被复制到“ holderhistory”中'
应用程序中将运行一个作业
i）收集holder表中的所有较旧的条目并复制到holderhistory表中
ii）从持有人表中删除旧条目
现在的问题是-持有人表中创建的墓碑过多。
默认情况下，墓碑将在10天（864000秒）gc_grace_seconds之后清除
但我不想将墓碑保留超过3个小时，
1），那么将 gc_grace_seconds 设置为3小时会很好吗？
2）还是将 default_time_to_live 设置为3小时好？
哪个是删除墓碑的最佳解决方案？
将gc_grace_seconds从10天减少到3小时又会有什么结果？我们将在哪里产生影响？
感谢任何帮助。
答案 0 :(得分：0)
如果您将GCGraceSeconds参数减小得太低，并且任何节点的恢复时间都比GCGraceSeconds长，在这种情况下，一旦这些节点之一恢复联机，就会错误地认为已接收到删除的所有节点实际上错过了写操作，它将开始修复所有其他节点。我建议使用efault_time_to_live并尝试一下。
答案 1 :(得分：0)
要回答你的具体情况：为表“的架的”只包含一个分区，你可以用一个“由分区键删除”语句删除整个分区，有效地创建一个单一的墓碑。
如果每天删除一次分区，则每天将有1个逻辑删除……这是完全可以接受的。
1）的gc_grace_seconds等于3个小时，如果RF> 1，则不能保证从3个小时以上的节点故障中持续恢复正常状态
2）的default_time_to_live等于3小时，插入后3小时创建一个逻辑删除将删除每条记录
因此您可以将默认gc_grace_seconds设置为10天，并注意使用DELETE FROM table WHERE PartitionKey = X
编辑：回答您有关提示切换的评论...
让我们说RF = 3，gc_grace_second = 3h，然后一个节点出现故障。其他两个副本继续接收突变（插入，更新，删除），但无法将其复制到脱机节点。在这种情况下，提示将暂时存储在磁盘上，如果死节点返回，将在以后发送。
但是提示将在gc_grace_seconds之后过期，直到永远不会发送。
现在，如果删除一行，它将在2个副本的sstable中生成一个逻辑删除，并在coordinator节点中生成一个提示。 3小时后，压缩管理器从联机节点中删除了逻辑删除，并且提示过期。
稍后，当死节点返回时，它仍然具有该行，并且不知道该行已被删除，因为副本上不存在提示，也没有更多的逻辑删除……因此，这是一个僵尸行。 >
答案 2 :(得分：0)