处理Cassandra写入失败的常见做法是什么?

时间:2013-04-15 14:58:21

标签: database cassandra consistency eventual-consistency

在doc [1]中,据说

if using a write consistency level of QUORUM with a replication factor
of 3, Cassandra will send the write to 2 replicas. If the write fails on
one of the replicas but succeeds on the other, Cassandra will report a 
write failure to the client. 

因此假设只有2个副本接收更新,写入失败。但由于最终的一致性,所有节点最终都会收到更新。

那么,我应该重试吗?或者只是把它当成它?

任何策略?

[1] http://www.datastax.com/docs/1.0/dml/about_writes

2 个答案:

答案 0 :(得分:3)

那些文档不太正确。无论一致性级别(CL)如何,都会将写入发送到所有可用副本。如果副本不可用,Cassandra将不会向下行节点发送请求。如果从一开始就没有足够的可用来满足CL,则抛出UnavailableException并且不会尝试对任何节点进行写入。

但是,写入仍然可以在某些节点上成功,并且会将错误返回给客户端。在[1]的示例中,如果在尝试写入之前一个副本已关闭,则写入的内容为真。

  

因此假设只有2个副本接收更新,写入失败。但   由于最终的一致性,所有节点都将收到更新   最后。

但请注意:写入失败并不能告诉您写入的节点数。它可能没有,所以写入最终可能不会传播。

  

那么,我应该重试吗?或者只是保持原样?

一般情况下,您应该重试,因为它可能根本不会写。当你从写作中成功返回时,你应该只把你的写作看作是写的。

如果你正在使用计数器,你应该小心重试。因为您不知道是否进行了写入,所以您可能会获得重复计数。对于计数器,您可能不想重试(因为通常会对至少一个节点进行写入,至少对于更高的一致性级别而言)。

答案 1 :(得分:0)

重试不会有太大变化。问题是你实际上无法知道数据是否仍然存在,因为Cassandra总是抛出相同的异常。

你几乎没有选择:

  • 使用cl = any启用提示和重试请求 - 成功的响应意味着至少创建了提示。所以你知道数据存在但尚无法访问。
  • 禁用提示并重试一次 - 成功的响应意味着至少节点可以接收数据。如果出现错误,请执行删除。
  • 使用astyanax及其重试策略
  • 更新到Cassandra 1.2并使用预写日志