Question

我正在AWS EC2上的24节点Cassandra 3.5群集上运行写入繁重的程序（10个线程以25K /秒写入峰值）（每个主机为c4.2xlarge类型：8个vcore和15G ram）

每隔一段时间，我的Java客户端使用DataStax驱动程序3.0.2就会出现写入超时问题：

com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency TWO (2 replica were required but only 1 acknowledged the write)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:73)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:26)
    at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
    at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
    at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:64)

错误很少发生并且以非常不可预测的方式发生。到目前为止，我无法将故障链接到任何特定的（例如程序运行时间，磁盘上的数据大小，一天中的时间，系统负载的指标，如CPU，内存，网络指标）尽管如此，它确实扰乱了我们的操作

我正在努力找到问题的根本原因。在网上寻找选项，我有点不知所措，例如

在“cassandra.yaml”中更改“write_request_timeout_in_ms”（已更改为5秒）
使用正确的“RetryPolicy”保持会话进行（已在ONE会话级别的一致性级别使用DowngradingConsistencyRetryPolicy）
更改缓存大小，堆大小等 - 从未尝试过这些b / c有充分的理由将它们作为根本原因折扣。

在我的研究过程中，有一点让人感到困惑的是，我从一个完全复制的集群中收到此错误，其中包含很少的ClientRequest.timeout.write事件：

我有一个完全复制的24节点集群，跨越5个aws区域。每个区域至少有2个数据副本
我的程序在会话级别（带有QueryOption的群集构建器）
当错误发生时，我们的Graphite图表注册了不超过三（3）个主机打嗝，即具有Cassandra.ClientRequest.Write.Timeouts.Count值
我已经将write_timeout设置为5秒。网络非常快（使用iperf3验证）和稳定

在纸面上，情况应该在Cassandra的失效保护范围内。但为什么我的程序仍然失败？这些数字不是它们看起来的那样吗？

Answer 1

看到超时或错误并不总是一件坏事，特别是如果您以更高的一致性级别进行写操作时，写操作仍然可以通过。

我看到您提到CL=ONE，您仍然可以在这里超时，但是写入（突变）仍然可以解决。我发现此博客非常有用：https://www.datastax.com/dev/blog/cassandra-error-handling-done-right。在发生错误时检查您的服务器端（节点）日志，以查看是否有诸如ERROR / WARN / GC暂停之类的事情（例如上述注释之一），此类事件可能导致节点无响应，因此超时或其他类型的错误。

如果更新是幂等的（理想情况下），则可以构建某种重试机制。

Cassandra“写超时”的本质是什么？

1 个答案: