Cassandra和终止连接 [英] Cassandra and defuncting connection

查看:348
本文介绍了Cassandra和终止连接的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个关于Cassandra的问题。我还没有找到任何不稳定的答案 ...
我在不同VM的3个节点(RackInferringSnitch)上建立了集群。我正在使用Datastax的Java驱动程序来读取和更新密钥空间(带有CSV)。
当一个节点关闭时(即:10.10.6.172),我收到此调试警告:

I've got a question about Cassandra. I haven't found any "understable answer" yet... I made a cluster build on 3 nodes (RackInferringSnitch) on differents VM. I'm using Datastax's Java Driver to read and update my keyspace (with CSVs). When one node is down (ie : 10.10.6.172), I've got this debug warning:

 INFO 00:47:37,195 New Cassandra host /10.10.6.172:9042 added
 INFO 00:47:37,246 New Cassandra host /10.10.6.122:9042 added
 DEBUG 00:47:37,264 [Control connection] Refreshing schema
 DEBUG 00:47:37,384 [Control connection] Successfully connected to /10.10.6.171:9042
 DEBUG 00:47:37,391 Adding /10.10.6.172:9042 to list of queried hosts
 DEBUG 00:47:37,395 Defuncting connection to /10.10.6.172:9042
 com.datastax.driver.core.TransportException: [/10.10.6.172:9042] Channel has been closed
at com.datastax.driver.core.Connection$Dispatcher.channelClosed(Connection.java:621)
at 
 [...]
 [...]  
 DEBUG 00:47:37,400 [/10.10.6.172:9042-1] Error connecting to /10.10.6.172:9042 (Connection refused: /10.10.6.172:9042)
 DEBUG 00:47:37,407 Error creating pool to /10.10.6.172:9042 ([/10.10.6.172:9042] Cannot connect)
 DEBUG 00:47:37,408 /10.10.6.172:9042 is down, scheduling connection retries
 DEBUG 00:47:37,409 First reconnection scheduled in 1000ms
 DEBUG 00:47:37,410 Adding /10.10.6.122:9042 to list of queried hosts
 DEBUG 00:47:37,423 Adding /10.10.6.171:9042 to list of queried hosts
 DEBUG 00:47:37,427 Adding /10.10.6.122:9042 to list of queried hosts
 DEBUG 00:47:37,435 Shutting down pool
 DEBUG 00:47:37,439 Adding /10.10.6.171:9042 to list of queried hosts
 DEBUG 00:47:37,443 Shutting down pool
 DEBUG 00:47:37,459 Connected to cluster: WormHole

我想知道是否需要处理此异常由我自己处理(我的意思是,如果该批处理是一次写操作,则当节点再次返回时,cassandra将执行正确的写操作...)

I wanted to know if I need to handle this exception or it will be handled by itself (I mean, when the node will be back again cassandra will do the correct write if the batch was a write...)

EDIT :当前一致性级别为ONE。

EDIT : Current consistency level is ONE.

推荐答案

DataStax驱动程序会跟踪哪个节点始终可用,并且r根据此信息进行查询(负载平衡)。它的执行方式基于您的 重新连接策略

The DataStax driver keeps track of which nodes are available at all times and routes queries (load balacing) based on this information. The way it does this is based on your reconnection policy.

当节点被检测为关闭等时,您将看到调试级别消息。这不必担心,因为驱动程序将重新路由到其他可用节点,它将还定期重试节点以了解它们是否已备份。如果您有问题,并且数据没有保存到Cassandra,您将看到超时错误。在这种情况下,无需采取任何措施。

You will see debug level messages when nodes are detected as down, etc. This is no cause for concern as the driver will re-route to other available nodes, it will also re-try the nodes periodically to find out if they are back up. If you had a problem and the data was not getting saved to Cassandra you would see timeout errors. No action necessary in this case.

这篇关于Cassandra和终止连接的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆