![]() |
1
3
是的,即使删除了cl.all,如果要保证没有恢复的数据,仍然需要运行修复。你只是在不知不觉中降低了它发生的可能性。 如果某个节点不可用于删除,则客户端的删除将失败(因为cl.all),但其他所有节点仍收到删除。即使你的应用会重试删除,也有可能失败(即你的应用服务器被流星击中)。因此,您有一个已被3个副本中的2个看到的删除。如果您降低了gc_的优雅度,并且没有运行repairs,那么其他的反熵措施(提示,读取repairs)可能无法确保墓碑(它们是尽最大努力而不是保证)在墓碑被压缩之前被第三个节点看到。下一次读取会接触到第三个节点,该节点具有原始数据,并且不存在表示该数据已被删除的墓碑,因此在将数据的读取修复到其他副本时会将其恢复。 您可以做的是将一条语句记录到某个地方,以指向cl.all超时或失败的时间。这并不是一个保证,因为你的应用程序可能在日志之前就死掉了,而失败并不意味着写操作并没有到达所有的副本——只是 可以 的未能写入。也就是说,我强烈建议只使用quorum(或local_quorum)。这样,您就可以在不损失可用性的情况下发生一些主机故障,因为您无论如何都需要对保证进行修复。 |
![]() |
2
1
当使用consistency=all发出查询时,具有该特定记录的令牌范围的每个节点都必须确认。因此,如果在此过程中某个节点关闭,则删除将失败,因为它无法达到所需的一致性=全部。
|
![]() |
Damilola · Cassandra无效查询:缺少一些群集密钥 7 年前 |