卡桑德拉操作超时

操作超时 - 只收到0的响应'，信息： '表示从服务器'，代码的错误消息：4608，稠度：1，接收：0， blockFor：1 ， isDataPresent：0， ...卡桑德拉操作超时

我每天都有几次尝试在我的cassandra集群上执行SELECT查询时发生此错误。我们在m1.large aws实例上有一个3节点的集群。他们大部分时间都成功了，但每过一段时间我们都会遇到上述错误。我们还没有生产，所以所有的桌子都很小。我们没有超过几千行的任何表，并且相同的查询在其他时间完成罚款。提高时间不是一种选择，我不相信它会解决问题（查询应该很短，并且错误中的查询每次都不相同）

这可能是一些连接过时节点之间还是网络问题？什么是测试这些的最佳方法？我也只在客户端看到这个错误，是否应该在cassandra日志中看到这个地方？

来源

2016-07-06 Alex Yurkowski

这实际上是从负责处理您的请求的C *服务器（又名'协调器'）返回的错误。

看起来您正在查询一致性级别为'ONE'，因此只有1个持有数据的副本需要响应服务器上cassandra.yaml文件中配置的read_request_timeout_in_ms内的协调器（默认值为5秒），但在这段时间内没有副本回复。

超时可能发生，您的应用程序应准备处理它们根据自己的喜好（或平出故障，重试，增加复制因子使其不太可能，等等）

这里有一些事情你应该考虑：

增加您正在查询数据的密钥空间的复制因子。如果您的复制因子为1，则依赖于1个节点可用于响应特定分区的查询。将您的RF增加到3这样的东西将使您的应用程序更好地适应性能不佳的节点或节点。
配置您的RetryPolicy根据您的行为方式重试读取操作。 nodejs-driver的默认设置是只重试一次，只有在received>blockFor（在你的情况下不是这样）。
在您的cassandra.yaml中增加read_request_timeout_in_ms。尽管如此，我仍然不鼓励这样做，除非你的配置/环境/查询不合适，否则5000毫秒应该足够绰绰有余。

来源

2016-07-06 19:06:52

我们目前使用的是射频（RF），所以数据至少包含2个节点。我减少了超时，因为我不相信失败的查询会成功。这样我们可以更快地失败。它看起来像默认情况下10秒钟内的范围查询超时。我知道我们应该能够处理失败，并且我们正在捕捉错误，但请求中的延迟对我们来说是个问题。我不认为一个3节点的集群应该经历与我们的负载超时（小）这是我最关心的问题。我不希望更多的用户超时，但这似乎与加载无关。 –

您是否在C *端进行任何类型的监控以查看是否可以对延迟进行任何可能的解释？我建议看一看nodetool cfstats，看看是否能揭示任何东西，并监控任何类型的os统计信息，看看是否能给出任何见解。另一件可能有趣的事情是启用查询跟踪，这将有助于解释为什么查询有时可能需要一段时间。 –

我们使用新的监督服务器和os统计数据，但没有直接与cassandra关联，但都看起来很好。我今天发现了这个实际问题，我们正在创建一个很长的feed，并且使用cassandra lucene插件进行的某个查询花了很长时间，我们一次性解雇了很多人。这只会偶尔发生，这就是为什么它很难追查。我改变了查询，而不是在我们的流程中使用插件和过滤器，现在它运行良好。谢谢！ –

卡桑德拉操作超时

回答

相关问题