Question

我使用ElasticSearch.NET和NEST来服务于.NET Web服务的调用。 ElasticClient是一个单例，因此它的连接池和故障转移应该在服务调用之间保持不变。

ElasticClient正在使用带有两个群集节点的SniffingConnectionPool。其中一个节点已经死亡，根本没有响应http流量。

我的理解是，SniffingConnectionPool应该检测到这一点并从它使用的节点中排除死连接 - 也就是说，所有Elasticsearch流量都应该发送到唯一的活动节点。

可悲的是，ElasticClient一直试图使用死节点，为webservice响应添加了很长的超时延迟。有没有人使用Elasticsearch.NET故障转移池取得任何成功？有没有人有任何想法我做错了什么，或者我还能尝试什么？

我已经尝试过切换到StaticConnectionPool，但问题仍然存在。

我已尝试过使用连接设置，但在http://nest.azurewebsites.net/elasticsearch-net/cluster-failover.html的doco中无法获得足够有用的理解。

这是我用来创建带有连接池的客户端的代码：

    private static IElasticClient _MakeClient(string[] injectedUris, string defaultIndex)
    {
        var settings = new ConnectionSettings(_GetIConnectionPool(injectedUris), defaultIndex);
        var connection = new ConnectionWithBackoffStrategy(
            new HttpConnection(settings));
        var client = new ElasticClient(settings, connection);
        return client;
    }

    private static IConnectionPool _GetIConnectionPool(string[] injectedUris)
    {
        var uris = injectedUris ?? ConfigurationManager.AppSettings["elasticSearchUrls"].Split(',');
        return new SniffingConnectionPool(uris.Select(uri => new Uri(uri)));
    }

我使用的是Nest 1.0.0-beta1。

Answer 1

ConnectionSettings有选择加入嗅探的方法，例如SniffOnConnectionFault(true)和SniffOnStartup(true)。

如果您选择加入这些，那么ElasticSearch.net将调用http://localhost:9200/_nodes/_all/clear?timeout=50

我相信这是为了证明节点是活的，但是弹性搜索文档中没有关于clear操作的信息。

python实现似乎暗示它只是调用一些可以快速返回的东西;虽然它有点可怕＆＃39;在对所有节点＆＃39;

的请求中看到clear

使用小超时进行嗅探请求，应该是一个快速的api调用

https://github.com/elasticsearch/elasticsearch-py/blob/master/elasticsearch/transport.py#L175

Elasticsearch.NET故障转移似乎不会排除死节点

1 个答案: