如何处理使用低级别.net Elasticsearch客户端的群集节点的突然丢失？

我已经建立了一个由三个弹性搜索节点组成的集群，所有符合条件的master都是最低要求的2。我已经配置了一个客户端，然后使用下面的代码使用带有静态连接池的低级客户端进行批量上传。如何处理使用低级别.net Elasticsearch客户端的群集节点的突然丢失？

我试图测试的是场景的实时故障，即有三个节点可用的启动客户端，然后随机丢弃一个（关闭虚拟机），但保持两个。但是，我没有看到我期望的行为，它不断尝试死亡节点。实际上，它在移动到下一个节点之前似乎需要大约六十秒。

我所期望的是做一个失败的尝试，并将该节点标记为可能已经死亡，但至少移动到下一个节点。奇怪的是，如果我在我的列表中只有三个节点中的两个节点启动我的应用程序，或者如果我在测试期间停止弹性搜索服务，而不是断电，则会出现这种情况。

是否有正确的方法来处理这种情况，并尽快将其移动到下一个可用节点？或者在尝试重新发布之前，我需要在我的代码中延期多达六十秒？

var nodes = new[] 
     { 
      new Node(new Uri("http://172.16.2.10:9200")), 
      new Node(new Uri("http://172.16.2.11:9200")), 
      new Node(new Uri("http://172.16.2.12:9200")) 
     }; 

     var connectionPool = new StaticConnectionPool(nodes); 

     var settings = new ConnectionConfiguration(connectionPool) 
      .PingTimeout(TimeSpan.FromSeconds(10)) 
      .RequestTimeout(TimeSpan.FromSeconds(20)) 
      .ThrowExceptions() 
      .MaximumRetries(3); 

     _lowLevelClient = new ElasticLowLevelClient(settings);

然后我已经包裹在一个尝试捕捉，我再试最多的前三次我认为这是一个失败的尝试，并恢复到一个错误的策略下。

ElasticsearchResponse<Stream> indexResponse = _lowLevelClient.Bulk<Stream>(data);

任何投入表示赞赏，

谢谢。

来源

2017-10-13 wtarr

您是否试图用SniffingConnectionPool替换StaticConnectionPool（一个嗅探连接池允许自己在运行时重新调用）？请参考：https：//www.elastic.co/guide/en/elasticsearch/client/net-api/current/connection-pooling.html –

客户端的测试包括故障转移方案的测试，其中the API conventions documentation is generated。具体来说，看一看的retry和failover文档

随着StaticConnectionPool，对此可以提出的要求是静态的，永远不会刷新节点，以反映可能加入和离开集群，但它们将被标记的节点为死如果不良反应返回，并将于连接设置取出旋转执行的请求的配置死时间，控制由DeadTimeout和MaxDeadTimeout。

响应的审计追踪应提供给定请求发生的事件的时间表，这是response.DebugInformation最容易看到的事件。作为Tests项目一部分的Virtual Clustering测试工具（an example）可能有助于确定您所处行为的正确设置。

来源

2017-10-15 03:59:01

谢谢，我玩过这些超时设置，默认回到60秒超时。除了拥有我自己的try catch/retry逻辑之外，我可以让我的请求最终在突然的节点丢失上成功。但是，我有些感觉到背景中有什么东西可以确定节点已经死亡，而不是失败的发布尝试，因为时间与我无关。我注意到超时将在60秒后发生，并且成功发布将在我重试约20秒后发生。也许在节点允许之前必须进行一些谈判？ – wtarr

如何处理使用低级别.net Elasticsearch客户端的群集节点的突然丢失？

回答

相关问题