Question

我已经建立了一个由三个弹性搜索节点组成的集群，所有这些节点都符合条件，其中2个是最低要求。我已经配置了一个客户端，然后使用带有静态连接池的低级客户端使用下面的代码批量上传。

我要测试的是实时故障转移方案，即启动具有三个可用节点的客户端，然后随机丢弃一个（关闭VM），但保持两个。但是我没有看到我期望的行为，它一直在尝试死节点。它实际上似乎需要大约六十秒才能移动到下一个节点。

我期望它做的是尝试失败并将该节点标记为可能已死，但至少转到下一个节点。奇怪的是，如果我只使用列表中可用的三个节点中的两个启动我的应用程序，或者如果我在测试期间停止弹性搜索服务而不是断电，这就是我得到的行为。

是否有正确的方法来处理这种情况并让它尽快移动到下一个可用节点？或者，在尝试重新发布之前，我是否需要在代码中退回最多60秒？

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);

接下来我把try包裹在try catch中，在我认为尝试失败并恢复错误策略之前，我最多重试三次。

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

赞赏任何意见，

谢谢。

Answer 1

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

使用StaticConnectionPool，可以向其发出请求的节点是静态的，并且永远不会刷新以反映可能加入和离开群集的节点，但它们将被标记为< em> dead 如果返回错误响应，并且将被轮流用于执行可配置 dead 时间的请求，由{{1}控制和连接设置上的DeadTimeout。

响应的审计跟踪应提供给定请求发生的时间表，最容易看到MaxDeadTimeout。作为测试项目一部分的虚拟群集测试工具（an example）可能有助于确定您所追求的行为的正确设置。

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

1 个答案: