据我了解，Cassandra中重新出现被删除数据的问题如下：
现在我的问题是：如果原始删除是在一致性 = ALL 的情况下发出的，那么所有节点要么有墓碑（在到期和压缩之前），要么根本没有数据（在到期和压缩之后）。即使我们没有在墓碑到期之前进行修复，也不应该产生僵尸。
这对吗？
【问题讨论】：
标签： cassandra
是的，如果您想保证没有恢复的数据，即使在删除时使用 CL.ALL，您仍然需要运行修复。你只是在你没有注意到它的情况下降低它发生的可能性。
如果一个节点不可用于删除，客户端的删除将失败（因为 cl.all），但其他节点仍然收到删除。即使您的应用程序将重试删除，也有可能失败（即您的应用程序的服务器被流星击中）。因此，您的 3 个副本中有 2 个已看到删除。如果您降低了 gc_grace 并且不运行修复，则其他反熵措施（提示、读取修复）可能无法确保在墓碑被压缩之前第三个节点看到墓碑（它们是尽力而不是保证）。下一次读取触及具有原始数据的第 3 个节点，并且不存在说明它已被删除的墓碑，因此您在读取修复到其他副本时恢复数据。
您可以做的是在某处记录一条语句，以便在出现 cl.all 超时或失败时指出。这不是保证，因为您的应用程序可能会在日志之前死亡，并且失败实际上并不意味着写入没有到达所有副本 - 只是它可能写入失败。也就是说，我强烈建议只使用 quorum（或 local_quorum）。这样一来，您就可以在不失去可用性的情况下发生一些主机故障，因为无论如何您都需要维修来保证。
【讨论】：
当使用 Consistency=ALL 发出查询时，具有该特定记录的令牌范围的每个节点都必须确认。因此，如果在此过程中某个 NODE 发生故障，则 DELETE 将失败，因为它无法达到所需的一致性=ALL。
因此，一致性=ALL，最终可能会导致集群中的每个节点都必须保持正常运行，否则查询将失败。这就是为什么人们建议使用像 QUORUM 这样的强度较低的一致性。因此，如果您想在 CONSISTENCY=ALL 处执行查询，您将牺牲 REPAIR 的高可用性
【讨论】：