elasticsearch: Как повторно инициализировать узел?

Question

elasticsearch 1.7.2 on CentOS

У нас есть кластер из 3 узлов, который работает нормально. Сетевая проблема привела к тому, что узел «B» потерял доступ к сети. (Затем выясняется, что узел C имел «minimum_master_nodes» как 1, а не 2).

Итак, теперь мы держимся за узел А.

Мы исправили проблемы на узлах B и C, но они отказываются подниматься и присоединяться к кластеру. На B и C:

# curl -XGET http://localhost:9200/_cluster/health?pretty=true 
{ 
    "error" : "MasterNotDiscoveredException[waited for [30s]]", 
    "status" : 503 
} 

elasticsearch.yml выглядит следующим образом (название на «б» и «в» узлы, отражены в названиях узлов на этих системах, кроме того, IP addys на каждом узле отражают 2 других узлов, ОДНАКО, на «с» узле, index.number_of_replicas был ошибочно установлен в 1.)

cluster.name: elasticsearch-prod 

node.name: "PROD-node-3a" 

node.master: true 

index.number_of_replicas: 2 

discovery.zen.minimum_master_nodes: 2 

discovery.zen.ping.multicast.enabled: false 

discovery.zen.ping.unicast.hosts: ["192.168.3.100", "192.168.3.101"] 

Мы понятия не имеем, почему они не будут вступать. У них есть видимость сети для A, и A может их видеть. Каждый узел правильно имеет два других определенных в «discovery.zen.ping.unicast.hosts:»

На В и С, журнал очень редко, и ничего не говорит нам:

# cat elasticsearch.log 
[2015-09-24 20:07:46,686][INFO ][node      ] [The Profile] version[1.7.2], pid[866], build[e43676b/2015-09-14T09:49:53Z] 
[2015-09-24 20:07:46,688][INFO ][node      ] [The Profile] initializing ... 
[2015-09-24 20:07:46,931][INFO ][plugins     ] [The Profile] loaded [], sites [] 
[2015-09-24 20:07:47,054][INFO ][env      ] [The Profile] using [1] data paths, mounts [[/ (rootfs)]], net usable_space [148.7gb], net total_space [157.3gb], types [rootfs] 
[2015-09-24 20:07:50,696][INFO ][node      ] [The Profile] initialized 
[2015-09-24 20:07:50,697][INFO ][node      ] [The Profile] starting ... 
[2015-09-24 20:07:50,942][INFO ][transport    ] [The Profile] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/10.181.3.138:9300]} 
[2015-09-24 20:07:50,983][INFO ][discovery    ] [The Profile] elasticsearch/PojoIp-ZTXufX_Lxlwvdew 
[2015-09-24 20:07:54,772][INFO ][cluster.service   ] [The Profile] new_master [The Profile][PojoIp-ZTXufX_Lxlwvdew][elastic-search-3c-prod-centos-case-48307][inet[/10.181.3.138:9300]], reason: zen-disco-join (elected_as_master) 
[2015-09-24 20:07:54,801][INFO ][http      ] [The Profile] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/10.181.3.138:9200]} 
[2015-09-24 20:07:54,802][INFO ][node      ] [The Profile] started 
[2015-09-24 20:07:54,880][INFO ][gateway     ] [The Profile] recovered [0] indices into cluster_state 
[2015-09-24 20:42:45,691][INFO ][node      ] [The Profile] stopping ... 
[2015-09-24 20:42:45,727][INFO ][node      ] [The Profile] stopped 
[2015-09-24 20:42:45,727][INFO ][node      ] [The Profile] closing ... 
[2015-09-24 20:42:45,735][INFO ][node      ] [The Profile] closed 

Как мы приносим весь зверь к жизни?

• Rebooting B и C не делает никакой разницы
• Меня не решается цикл А, как это то, что наше приложение удар ...

Answer 1

Ну, мы не знаем, что привело это к жизни, но это волшебно возвратилось.

Я считаю, что перенаправление осколков (показано здесь: elasticsearch: Did I lose data when two of my three nodes went down?) заставил узлы присоединиться к кластеру. Наша теория состоит в том, что узел А, единственный сохранившийся узел, не был «здоровым» мастером, потому что знал, что один осколок («р» разрез осколка 1, как указано здесь: elasticsearch: Did I lose data when two of my three nodes went down?) не был выделен.

Поскольку хозяин знал, что это не было цело, остальные узлы отказались присоединиться к кластеру, метание «MasterNotDiscoveredException»

После того, как мы получили все «р» Осколки назначены выживший узел, остальные узлы объединились и сделали весь реплицирующий танец.

ОДНАКО Данные были потеряны путем выделения такого осколка. В конечном итоге мы создали новый кластер и перестраиваем индекс (который занимает несколько дней).