Cassandra 删除问题答案

【问题标题】：Cassandra Delete issueCassandra 删除问题
【发布时间】：2015-03-26 23:43:56
【问题描述】：

如果我们删除了一致性级别为 QUORUM 的行，并且我们所有的读取都使用相同的一致性级别，那么删除的记录如何再次出现。

例如，在 RF=3 且一致性级别 = QUORUM 的 3 节点集群中。

我已经删除了具有一致性 QUORUM 的行，当时一个节点出现故障。所以故障节点无法赶上这次删除。

让 Cassandra 在完全压缩时删除每个节点中的行。从这两个节点中删除行后，考虑故障节点变为活动状态。

由于我们的一致性级别是 QUORUM，我们将从任何副本节点之一获得零结果，并且协调器可以假设该行已被删除并向客户端返回 null。

我的疑问是为什么 cassandra 等待 gc_grace_seconds 才能从节点中完全删除行。

【问题讨论】：

标签： cassandra

【解决方案1】：

因为如果故障节点在其他2个节点的数据被完全删除后恢复，集群将不知道数据是否被删除，而这个节点宕机，或者数据被插入，但是刚刚失败由于其他原因被复制到其他 2 个节点，例如，因为这 2 个节点在写入期间已启动，但随后崩溃并被替换。

换句话说，宽限期提供了足够的时间让所有节点在任何这些情况下同步所有数据。这也是为什么需要定期在这个宽限期内完成对集群的一轮修复

【讨论】：

如果我错了，请纠正..我认为通过计算当前时间，所有墓碑和所有超过 gc 宽限期的墓碑都有一个时间戳 - 墓碑中的时间将在主要压缩时被删除。
如果这是正确的有一些已删除的记录将超过宽限期，我们怎么能说我们可能必须在宽限期到期之前恢复失败的节点
是的。节点需要在宽限期内返回和修复，或者退出。已修复，因为墓碑必须在该节点上复制，然后才能从其他节点删除
您好，感谢您的回复。我需要再澄清一下。
这就是为什么不断修复集群中的节点是Cassandra数据库维护的一个非常重要的方面。您希望集群中的数据在节点之间始终保持同步。暗示的移交可能会或可能不会完全涵盖轻微的服务器故障（我个人不会完全依赖它）。但是，加上不断的修复工作，您可以确定在前 9 天中，服务器有足够的时间修复所有数据。但我还要说 - 如果您的服务器关闭了几天 - 重建它会更安全。