Elasticsearch Unicast Странное поведение при кластеризации - PullRequest
0 голосов
/ 04 сентября 2018

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

0.0.0.0:9200 (elasticsearch)
0.0.0.0:9201 (test-1)

Узел на 9200 находится в кластере elasticsearch (возможно, по умолчанию cluster.name). Узел на 9201 находится в кластере test-1. (Дополнительно, важно или нет, я связываю network.host с обоих узлов с 0.0.0.0)

Я хочу присоединить новый узел к test-1. Когда я оставляю параметр discovery.zen.ping.unicast.hosts закомментированным в одиночку, новый узел успешно присоединяется к test-1. Однако, когда я устанавливаю что-то другое, например, ["0.0.0.0"] или ["127.0.1"], он не может присоединиться ...

Присоединение нового узла к elasticsearch не вызывает проблем. ["0.0.0.0"], ["127.0.1"] и ["IP"] все работали хорошо. (Но ["0.0.0.0", "ANOTHER-IP"] не удалось ... Пожалуйста, ответьте об этом, если возможно ...)

Что вызывает эту проблему присоединения? Кто-нибудь сталкивался с подобными проблемами?

1 Ответ

0 голосов
/ 05 сентября 2018

discovery.zen.ping.unicast.hosts должен иметь IP-адреса всех узлов, присоединяющихся к кластеру. Сделайте это для всех узлов в кластере и используйте IP-адреса не 0.0.0.0 или 127.0.0.1.

Поскольку ваш новый узел пытается присоединиться к кластеру test-1, вы можете попытаться изменить порт нового узла на 9201 и посмотреть, присоединяется ли он.

Минимальные вещи, необходимые для формирования кластера:

  1. То же самое cluster.name
  2. поставить разные node.name
  3. discovery.zen.ping.unicast.hosts - IP-адреса всех узлов в кластере.

gateway.recover_after_nodes и discovery.zen.minimum_master_nodes - прокомментируйте эти строки, если они уже не так для всех узлов кластера.

Наконец, проверьте настройки брандмауэра и отключите брандмауэр, если это необходимо. Проверьте, могут ли узлы общаться друг с другом.

...