Question

我最近遇到过这样的情况：

我的群集有3个节点。 1不是数据节点，永远不能成为主节点。另外2个可以。所有这些节点的最小主节点都设置为2.

2个数据节点与所有分片存储完全相同的索引。 1只是另一个的复制品。

其中1个节点崩溃并且必须重新启动，但之后即使我看到它正在尝试，也无法重新加入群集。

以下是我在日志中看到的内容：

[2014-03-12 08:07:31,571][INFO ][discovery.zen] [Search 6] failed to send join 
request to master [[Search 6][Zsg_fKviRW6eJJG3aYIWeA][BLAHBLAH]
[inet[/BLAHBLAH:9300]]],
reason [org.elasticsearch.transport.RemoteTransportException: [Search 6]
[inet[/BLAHBLAH:9300]][discovery/zen/join];
org.elasticsearch.ElasticsearchIllegalStateException:
Node [[Search 6][vwurISIMTTC-Ra1EmiI8vA][BLAHBLAH][inet[/BLAHBLAH:9300]]]
not master for join request from [[Search 6][vwurISIMTTC-Ra1EmiI8vA]
[BLAHBLAH [inet[/BLAHBLAH:9300]]]]

（注意上面用BLAHBLAH覆盖了IP。）

这是什么意思？

Answer 1

not master for join request

此错误表示clusterJoinRequest中master的nodeId与接收请求的主节点的实际nodeId不匹配。

您可以在日志中看到localNode选择了一个带有 Zsg_fKviRW6eJJG3aYIIA ID的主人：

[搜索6]无法向主人发送加入请求[[搜索 6] [ Zsg_fKviRW6eJJG3aYIIA ] [BLAHBLAH] [inet [/ BLAHBLAH：9300]]]

但是收到加入请求的地址的实际nodeId是 vwurISIMTTC-Ra1EmiI8vA ：

节点[[搜索 6] [ vwurISIMTTC-Ra1EmiI8vA ] [BLAHBLAH] [inet [/ BLAHBLAH：9300]]]不掌握加入请求

奇怪的是，日志显示发送请求的节点与接收请求的节点相同。你是如何获得节点的地址的？此外，所有节点都具有相同的名称吗？如果没有，您可能只想重新启动以重置nodeId。

节点[[搜索 6] [ vwurISIMTTC-Ra1EmiI8vA ] [BLAHBLAH] [inet [/ BLAHBLAH：9300]]]不掌握来自[[搜索6] [ vwurISIMTTC-Ra1EmiI8vA ]的加入请求[BLAHBLAH [INET [/ BLAHBLAH：9300]]]]

ElasticSearch：如果发生裂脑，群集是否可以拒绝副本节点？

1 个答案: