Настройка обнаружения сервера Elasticsearch - PullRequest
8 голосов
/ 09 ноября 2011

Я установил сервер ElasticSearch, на котором я работаю:

$ ./elasticsearch -f
 {0.18.2}[11698]: initializing ...
 loaded [], sites []
 {0.18.2}[11698]: initialized
 {0.18.2}[11698]: starting ...
 bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/192.168.1.106:9300]}
 new_master [Stingray][ocw4qPdmSfWuD9pUxHoN1Q][inet[/192.168.1.106:9300]], reason: zen-disco-join (elected_as_master)
 elasticsearch/ocw4qPdmSfWuD9pUxHoN1Q
 recovered [0] indices into cluster_state
 bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.1.106:9200]}
 {0.18.2}[11698]: started

Как я могу настроить клиент Java для подключения к этому серверу?Я просто:

node.client=true

, но после попытки подключения я получаю:

org.elasticsearch.discovery.MasterNotDiscoveredException: 
    at org.elasticsearch.action.support.master.TransportMasterNodeOperationAction$3.onTimeout(TransportMasterNodeOperationAction.java:162)

Если я настраиваю Java-клиент как:

node.data=false

Я получаю следующие журналы:

INFO main node:internalInfo:93 - [Stark, Tony] {0.18.2}[13008]: starting ...
INFO main transport:internalInfo:93 - [Stark, Tony] bound_address {inet[/0:0:0:0:0:0:0:0:9301]}, publish_address {inet[/192.168.1.106:9301]}
INFO elasticsearch[Stark, Tony]clusterService#updateTask-pool-13-thread-1 service:internalInfo:93 - [Stark, Tony] new_master [Stark, Tony][WkNn96hgTkWXRnsR0EOZjA][inet[/192.168.1.106:9301]]{data=false}, reason: zen-disco-join (elected_as_master)

Как я понял, это означает, что этот новый узел (должен быть клиентским узлом) сделал себя новым главным узлом.И я не из журнала, что он найден и подключен к любому другому узлу.

И сервер, и клиент запускаются на одной машине.192.168.1.106:9200 доступны из браузера.

И я не могу найти хорошую документацию о конфигурации обнаружения.Где я могу прочитать больше о конфигурациях ElasticSearch?А как настроить клиент Java?

Ответы [ 6 ]

13 голосов
/ 11 ноября 2011

Наиболее вероятной причиной этого сбоя является брандмауэр на вашем компьютере, который блокирует трафик многоадресного обнаружения на порту 54328. Во время первоначального обнаружения и клиент, и ведущий вещают на этом порту и не получают ответ друг от друга. Вот почему, когда вы указываете node.client = true, клиентский узел (который не может быть главным) завершается неудачно с MasterNotDiscoveredException, а узел без данных выбирает себя в качестве главного.

9 голосов
/ 15 декабря 2011

Я столкнулся с той же проблемой и, используя IP-номера в файле конфигурации, решил ее для меня.

в /config/elasticsearch.yml

раскомментируйте и измените настройку network.hostto:

network.host: 127.0.0.1

Вы также можете изменить это на IP-адрес своего устройства в ifconfig.

5 голосов
/ 23 июля 2012

У меня была такая же проблема. В конце концов оказалось, что у меня возникла проблема с брандмауэром, поскольку мой брандмауэр (в Ubuntu) блокировал порты ElasticSearch. Я использую брандмауэр по умолчанию в Ubuntu, ufw .

Итак, чтобы открыть порты, я запустил следующие команды на терминале:

sudo ufw allow proto tcp to any port 9200:9400
sudo ufw allow proto tcp to any port 54328

Мой кластер работает локально на 9200, и все мои клиенты открываются на 9300+. Итак, я просто открыл диапазон 9200-9400 для них. 54328 для многоадресной передачи.

Просто для полноты: я также использовал TransportClient, который работает, но я добавил жестко закодированный мой localhost к адресу, на котором будет работать TransportClient. Не очень хорошая вещь для производственного кода :-)

2 голосов
/ 29 апреля 2016

Столкнулся с той же проблемой, когда узлы не смогли выбрать мастер при перезапуске узлов.

Проблема заключается в связи узлов между собой.

Пожалуйста, убедитесь, что в журналах упругого поиска указано, что перезапуск узла говорит

  publish_address {127.0.0.1:9200}
  or
  publish_address {0.0.0.1:9200}

Это означает, что текущий узел не публикует свой IP-адрес для других узлов, и, следовательно, узлы не будут распознавать этот узел, даже если IP-адрес узла может присутствовать в discovery.zen.ping.unicast.hosts

Решение Сделайте следующие изменения вasticsearch.yml. Добавить

 network.host: _non_loopback:ipv4_
 and restart the node.
 Ensure that the bound address now shows the <IP address>:<port no> and not the localhost.

Это означает, что теперь ваш узел доступен для обнаружения. Второй шаг, чтобы сделать его доступным для обнаружения в кластере, - это добавить ip-адрес узла в списки одноадресных хостов всех главных узлов, чтобы всякий раз, когда у нас был новый мастер, узел мог быть обнаружен новым мастером.

   Add the node IP to the discovery.zen.ping.unicast.hosts 
   list of hosts of all the masters to make it disoverable. A masterpings all the 
   nodes present in the unicast list.
1 голос
/ 22 июня 2015

Настройка сетевого хоста на localhost:

network.host: 127.0.0.1

1 голос
/ 10 ноября 2011

Примерно так должно работать:

        Settings s = ImmutableSettings.settingsBuilder()
                .put(this.settings)
                .build();
        TransportClient client = new TransportClient(s);
        client.addTransportAddress(new InetSocketTransportAddress(
                "localhost",
                9300)
        );

Что меня расстроило, так это то, что я изначально пытался подключить клиент к 9200, а не к 9300. Руководство по настройкам выше можно найти по http://www.elasticsearch.org/guide/reference/java-api/client.html

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...