Первичный осколок не активен или не назначен - это известный узел?

Проблема : кажется, что elasticsearch перестает отправлять данные в kibana из-за превышения дискового пространства. Вы получаете org.elasticsearch.action.UnavailableShardsException и тайм-аут в связи с тем, что ваш основной сегмент неактивен . Чтобы укрепить теорию - запустите sudo df -h, и вы, вероятно, получите высокий процент объемов данных из /var/data на вашем компьютере.

Объяснение: согласно документации по Распределение сегментов дискового пространства elasticserach, Elasticsearch учитывает доступное дисковое пространство на узле, прежде чем принять решение о выделении новых сегментов этому узлу или активном перемещении сегментов с этого узла. У вас есть 4 переменные, которые необходимо установить, чтобы переопределить выделение сегмента дискового пространства по умолчанию.

1. cluster.routing.allocation.disk.threshold_enabled По умолчанию установлено значение true. Установите значение false, чтобы отключить решение о выделении диска. 2. cluster.routing.allocation.disk.watermark.low Управляет низким уровнем водяной знак для использования диска. По умолчанию он составляет 85%, что означает, что Elasticsearch не будет выделять шарды узлам, имеющим более Использовано 85% диска. Он также может быть установлен в абсолютное значение байта (например, 500 МБ), чтобы Elasticsearch не выделял осколки, если их размер меньше указанное количество места доступно. Этот параметр не действует на первичных осколках вновь созданных индексов, но предотвратит их реплики от размещения.

3. cluster.routing.allocation.disk.watermark.high Управляет высоким водяной знак. По умолчанию это 90%, что означает, что Elasticsearch попытается для перемещения шардов от узла, использование диска которого превышает 90%. Это также может быть установлено абсолютное значение байта (аналогично младшему водяной знак), чтобы переместить сегменты подальше от узла, если он имеет меньше указанное количество свободного места. Этот параметр влияет на распределение все шарды, выделенные ранее или нет.

4. cluster.routing.allocation.disk.watermark.flood_stage Управляет водяной знак стадии наводнения. По умолчанию это 95%, что означает, что Elasticsearch обеспечивает блок индекса только для чтения (index.blocks.read_only_allow_delete) по каждому индексу, который имеет один или несколько сегментов, выделенных на узле, который имеет хотя бы один диск, превышающий стадию флуда. Это последнее средство чтобы узлам не хватало места на диске. Индексный блок автоматически освобождается, когда использование диска становится ниже максимального водяной знак.

Решение . Теперь давайте выполним вызов API, отредактируем конфигурацию и увеличим ограничение на выделение сегментов дискового пространства (с 90 по умолчанию до 95–97%):

 curl -XPUT -H 'Content-Type: application/json' 'localhost:9200/_cluster/settings' 
-d '{  "transient":{
 "cluster.routing.allocation.disk.watermark.low":"95%",
"cluster.routing.allocation.disk.watermark.high": "97%",
"cluster.routing.allocation.disk.watermark.flood_stage": "98%",
"cluster.info.update.interval": "1m"
}}'

В моем случае виноват порт 9300. Он был заблокирован.

Elasticsearch будет привязан к одному порту как для HTTP, так и для API узлов / транспорта.

Сначала он пробует самый нижний из доступных портов, а если он уже занят, пробует следующий. Если вы запустите на своем компьютере один узел, он будет связываться только с 9200 и 9300.

Итак, я разблокировал порт 9300, и все готово.

В REDHAT linux для разблокировки порта.

sudo firewall-cmd --zone=public --add-port=9300/tcp --permanent
sudo firewall-cmd --reload
sudo iptables-save | grep 9300

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

Как только я вывел все узлы данных в балансировщик нагрузки, моя проблема была исправлена.