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

回答您的特殊情况：由于表'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小时后，压缩管理器将删除联机节点中的逻辑删除标记，提示将过期。
稍后，当您的死节点返回时，它仍保留该行，并且它无法知道该行已被删除，因为复制副本上不存在任何提示和墓碑。。。因此，这是一个僵尸行。

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