我正在 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、内存、网络指标) 尽管如此,它确实扰乱了我们的操作。
我试图找到问题的根本原因。在网上寻找选项,我对那里的所有线索感到有些不知所措,例如
在我的研究过程中,有一件事情真的很令人困惑,我从一个完全复制的集群中得到这个错误,只有很少的 ClientRequest.timeout.write 事件:
从理论上讲,这种情况应该在 Cassandra 的故障安全范围内。但是为什么我的程序还是失败了?数字不是看起来的那样吗?
最佳答案
看到超时或错误并不总是一件坏事,尤其是如果您以更高的一致性级别进行写入,则写入可能仍会通过。
我看到你提到CL=ONE
你仍然可以在这里超时,但写(突变)仍然通过。我发现这个博客真的很有用:https://www.datastax.com/dev/blog/cassandra-error-handling-done-right .在错误发生时检查您的服务器端(节点)日志,看看您是否有诸如 ERROR/WARN/GC 暂停之类的事情(如上面提到的评论之一),这些类型的事件可能导致节点无响应,因此超时或其他类型的错误。
如果您的更新是幂等的(理想情况下),那么您可以构建一些重试机制。
关于cassandra - Cassandra "write timeout"的性质是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39304074/