ElasticSearch: неназначенные осколки, как исправить?

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

# v0.90.x and earlier
curl -XPUT 'localhost:9200/_settings' -d '{
    "index.routing.allocation.disable_allocation": false
}'

# v1.0+
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"
    }
}'

Затем Elasticsearch переназначит шарды как обычно. Это может быть медленным, рассмотрите возможность увеличения indices.recovery.max_bytes_per_sec и cluster.routing.allocation.node_concurrent_recoveries, чтобы ускорить его.

Если вы по-прежнему сталкиваетесь с проблемами, вероятно, что-то еще не так, поэтому поищите ошибки в журналах Elasticsearch. Если вы видите EsRejectedExecutionException, ваши пулы потоков могут быть слишком маленькими < / а>.

Наконец, вы можете явно переназначить сегмент узлу с помощью перенаправить API.

# Suppose shard 4 of index "my-index" is unassigned, so you want to
# assign it to node search03:
curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
    "commands": [{
        "allocate": {
            "index": "my-index",
            "shard": 4,
            "node": "search03",
            "allow_primary": 1
        }
    }]
}'

Хорошо, я решил это с некоторой помощью службы поддержки ES. Выполните следующую команду API на всех узлах (или узлах, которые, по вашему мнению, являются причиной проблемы):

curl -XPUT 'localhost:9200/<index>/_settings' \
    -d '{"index.routing.allocation.disable_allocation": false}'

где <index> - это индекс, который, по вашему мнению, является виновником. Если вы не знаете, просто запустите это на всех узлах:

curl -XPUT 'localhost:9200/_settings' \
    -d '{"index.routing.allocation.disable_allocation": false}'

Я также добавил эту строку в свою конфигурацию yaml, и с тех пор любые перезапуски сервера / службы не возникали проблем. Осколки немедленно перераспределяются обратно.

FWIW, чтобы ответить на часто задаваемый вопрос, установите MAX_HEAP_SIZE на 30 ГБ, если на вашем компьютере не менее 60 ГБ ОЗУ, и в этом случае установите его на половину доступной памяти.

использованная литература

• Информация о распределении сегментов

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

NODE="YOUR NODE NAME"
IFS=$'\n'
for line in $(curl -s 'localhost:9200/_cat/shards' | fgrep UNASSIGNED); do
  INDEX=$(echo $line | (awk '{print $1}'))
  SHARD=$(echo $line | (awk '{print $2}'))

  curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
     "commands": [
        {
            "allocate": {
                "index": "'$INDEX'",
                "shard": '$SHARD',
                "node": "'$NODE'",
                "allow_primary": true
          }
        }
    ]
  }'
done

Единственное, что у меня сработало, это изменение number_of_replicas (у меня было 2 реплики, поэтому я изменил его на 1, а затем снова на 2).

Первый:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 1
     }
}

Потом:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 2
     }
}

(Я уже ответил на это в этом вопросе)

Я тоже столкнулся с подобной ошибкой. Это случилось со мной, потому что один из моих узлов данных был заполнен и из-за чего не удалось выделить шарды. Если есть неназначенные осколки, и ваш кластер КРАСНЫЙ, а несколько индексов также КРАСНЫЕ, в этом случае я выполнил следующие шаги, и они сработали как чемпион.
в инструменте разработки kibana -

GET _cluster/allocation/explain

Если есть какие-либо неназначенные осколки, вы получите подробную информацию, иначе будет выдана ОШИБКА.

просто запустив команду ниже, все решит -

POST _cluster/reroute?retry_failed

Спасибо -
https://github.com/elastic/elasticsearch/issues/23199#issuecomment-280272888.

Elasticsearch автоматически выделяет осколки, если в приведенной ниже конфигурации установлено значение all. Эту конфигурацию также можно установить с помощью rest api cluster.routing.allocation.enable: все

Если даже после применения приведенной ниже конфигурации es не может автоматически назначить шарды, вам придется принудительно назначить шарды самостоятельно. официальная ссылка ES для этого

Я написал сценарий для принудительного назначения всех неназначенных шардов в кластере.

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

#!/bin/bash
array=( node1 node2 node3 )
node_counter=0
length=${#array[@]}
IFS=$'\n'
for line in $(curl -s 'http://127.0.0.1:9200/_cat/shards'|  fgrep UNASSIGNED); do
    INDEX=$(echo $line | (awk '{print $1}'))
    SHARD=$(echo $line | (awk '{print $2}'))
    NODE=${array[$node_counter]}
    echo $NODE
    curl -XPOST 'http://127.0.0.1:9200/_cluster/reroute' -d '{
        "commands": [
        {
            "allocate": {
                "index": "'$INDEX'",
                "shard": '$SHARD',
                "node": "'$NODE'",
                "allow_primary": true
            }
        }
        ]
    }'
    node_counter=$(((node_counter)%length +1))
done

Сегодня я столкнулся с той же проблемой распределения шардов. Скрипт, который W. Эндрю Ло III, предложенный в своем ответе, не сработал для меня, поэтому я немного изменил его, и он, наконец, сработал:

#!/usr/bin/env bash

# The script performs force relocation of all unassigned shards, 
# of all indices to a specified node (NODE variable)

ES_HOST="<elasticsearch host>"
NODE="<node name>"

curl ${ES_HOST}:9200/_cat/shards > shards
grep "UNASSIGNED" shards > unassigned_shards

while read LINE; do
  IFS=" " read -r -a ARRAY <<< "$LINE"
  INDEX=${ARRAY[0]}
  SHARD=${ARRAY[1]}

  echo "Relocating:"
  echo "Index: ${INDEX}"
  echo "Shard: ${SHARD}"
  echo "To node: ${NODE}"

  curl -s -XPOST "${ES_HOST}:9200/_cluster/reroute" -d "{
    \"commands\": [
       {
         \"allocate\": {
           \"index\": \"${INDEX}\",
           \"shard\": ${SHARD},
           \"node\": \"${NODE}\",
           \"allow_primary\": true
         }
       }
     ]
  }"; echo
  echo "------------------------------"
done <unassigned_shards

rm shards
rm unassigned_shards

exit 0

Я не гуру Bash, но сценарий действительно работал в моем случае. Обратите внимание, что вам необходимо указать соответствующие значения для переменных «ES_HOST» и «NODE».

В моем случае была достигнута верхняя граница места на жестком диске.

Посмотрите эту статью: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html.

В основном я бегал:

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "90%",
    "cluster.routing.allocation.disk.watermark.high": "95%",
    "cluster.info.update.interval": "1m"
  }
}

Таким образом, он будет выделять, если используется <90% пространства на жестком диске, и перемещать осколок на другую машину в кластере, если используется> 95% пространства на жестком диске; и он проверяет каждую минуту.

В моем случае, когда я создаю новый индекс, тогда number_of_replicas по умолчанию устанавливается как 1. И число узлов в моем кластере был только один, поэтому не было дополнительного узла для создания реплики, поэтому состояние здоровья стало желтым. Итак, когда я создал индекс со свойством settings и установил number_of_replicas как 0. Тогда все заработало. Надеюсь это поможет.

PUT /customer
{
    "settings": {
        "number_of_replicas": 0
    }
}

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

Надеюсь, это кому-то поможет! :)

У меня тоже была эта проблема, и я нашел простой способ ее решить.

• Получить индекс неназначенных шардов

  $ curl -XGET http://172.16.4.140:9200/_cat/shards
  

• Установите инструменты куратора и используйте его для удаления индекса

  $ curator --host 172.16.4.140 delete indices --older-than 1 \
         --timestring '%Y.%m.%d' --time-unit days --prefix logstash
  

  ПРИМЕЧАНИЕ. В моем случае индекс - это журнал дня 2016-04-21.

• Затем проверьте шарды еще раз, все неназначенные шарды исчезнут!

У меня была такая же проблема, но основной причиной была разница в номерах версий (1.4.2 на двух узлах (с проблемами) и 1.4.4 на двух узлах (нормально)). Первый и второй ответы (установка index.routing.allocation.disable_allocation на false и установка cluster.routing.allocation.enable на all) не сработали.

Однако ответ @Wilfred Hughes (установка "cluster.routing.allocation.enable" на "all" с использованием переходного процесса) дал мне ошибку со следующим утверждением:

[НЕТ (версия целевого узла [1.4.2] старше, чем версия исходного узла [1.4.4])]

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

Я тоже встречаюсь с этой ситуацией и наконец исправил ее.

Сначала опишу свою ситуацию. У меня есть два узла в кластере ElasticSearch, они могут найти друг друга, но когда я создал индекс с настройками «number_of_replicas»: 2, «number_of_shards»: 5, ES показывает желтый сигнал, а unassigned_shards - 5.

Проблема возникает из-за того, что значение number_of_replicas, когда я устанавливаю его значение на 1, все в порядке.

Для меня это было решено путем запуска из консоли разработчика: «POST / _cluster / reroute? Retry_failed»

.....

Я начал с просмотра списка индексов, чтобы увидеть, какие индексы были красными, а затем запустил

"получить /_cat/shards?h=[INDEXNAME ],shard,prirep,state,unassigned.reason"

и увидел, что осколки застряли в состоянии ALLOCATION_FAILED, поэтому повторная попытка вызвала повторную попытку выделения.

В моем случае к кластеру присоединялся старый узел со старыми общими ресурсами, поэтому нам пришлось отключить старый узел и удалить индексы с неназначенными шардами.

Я попробовал несколько из вышеперечисленных предложений, но, к сожалению, ни одно из них не сработало. У нас есть индекс «Журнал» в нашей нижней среде, куда приложения записывают свои ошибки. Это кластер с одним узлом. Для меня это решило то, что я проверил файл конфигурации YML для узла и убедился, что у него все еще есть настройка по умолчанию "gateway.expected_nodes: 2". Это отменяло любые другие настройки, которые у нас были. Всякий раз, когда мы создавали индекс на этом узле, он пытался распространить 3 из 5 осколков на фантомный 2-й узел. Следовательно, они будут отображаться как неназначенные, и их нельзя будет переместить на 1-й и единственный узел.

Решением было отредактировать конфигурацию, изменить параметр gateway.expected_nodes на 1, чтобы он прекратил поиск своего брата, которого никогда не найти в кластере, и перезапустил экземпляр службы Elastic. Кроме того, мне пришлось удалить индекс и создать новый. После создания индекса все шарды появились на 1-м и единственном узле, и ни один из них не был назначен.

# Set how many nodes are expected in this cluster. Once these N nodes
# are up (and recover_after_nodes is met), begin recovery process immediately
# (without waiting for recover_after_time to expire):
#
# gateway.expected_nodes: 2
gateway.expected_nodes: 1

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

Другой возможной причиной неназначенных сегментов является то, что в вашем кластере работает более одной версии двоичного файла Elasticsearch.

репликация шарда из более новой версии в предыдущие не будет работать

Это может быть основной причиной неназначенных сегментов.

Elastic Documentation - непрерывный процесс обновления

Я столкнулся с той же проблемой. Этого можно избежать, временно установив для выделения сегментов значение false перед перезапуском elasticsearch, но это не исправляет неназначенные сегменты, если они уже есть.

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

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

Я попытался удалить неназначенные шарды или вручную назначить их конкретному узлу данных. Это не сработало, потому что все время появлялись неназначенные осколки, а состояние здоровья было "красным" снова и снова. Затем я заметил, что один из узлов данных застрял в состоянии «перезапуска». Уменьшил количество узлов данных, убил его. Проблема больше не воспроизводится.

У меня было два индекса с неназначенными осколками, которые, похоже, не работали с самовосстановлением. В конце концов я решил эту проблему, временно добавив дополнительный узел данных ^[1]. После того, как индексы стали работоспособными и все стало зеленым, я удалил лишний узел, и система смогла (снова) повторно сбалансировать и перейти в работоспособное состояние.

Рекомендуется избегать одновременного отключения нескольких узлов данных (именно так я попал в это состояние). Вероятно, мне не удалось сохранить какие-либо копии / реплики хотя бы для одного из осколков. К счастью, Kubernetes сохранил дисковое хранилище и повторно использовал его, когда я перезапустил узел данных.

... Прошло какое-то время ...

Что ж, на этот раз простое добавление узла, похоже, не сработало (после нескольких минут ожидания, чтобы что-то произошло), поэтому я начал ковыряться в REST API.

GET /_cluster/allocation/explain

Это показал мой новый узел с "decision": "YES".

Кстати, все ранее существовавшие узлы имели "decision": "NO" из-за "the node is above the low watermark cluster setting". Так что, вероятно, это был другой случай, чем тот, который я рассматривал ранее.

Затем я сделал следующий простой POST ^[2] без тела, который запустил процесс ...

POST /_cluster/reroute

Прочие примечания:

• Очень полезно: https://datadoghq.com/blog/elasticsearch-unassigned-shards

• Что-то еще, что может сработать. Установите cluster_concurrent_rebalance на 0, затем на null - как я демонстрирую здесь.

^{[1] В Kubernetes довольно легко сделать, если у вас достаточно места: просто масштабируйте набор с отслеживанием состояния через панель управления.}

^{[2] Используя интерфейс Kibana "Dev Tools", мне не пришлось возиться с оболочками SSH / exec.}

Я просто сначала увеличил

"index.number_of_replicas"

на 1 (подождите, пока узлы не будут синхронизированы), а затем уменьшил его на 1, что эффективно удаляет неназначенные сегменты, и кластер снова становится зеленым без риска потери каких-либо данных.

Я считаю, что есть способы получше, но мне так легче.

Надеюсь это поможет.

При работе с поврежденными шардами вы можете установить коэффициент репликации равным 0, а затем вернуть его к исходному значению. Это должно очистить большую часть, если не все ваши поврежденные шарды, и переместить новые реплики в кластер.

Настройка индексов с неназначенными репликами для использования коэффициента репликации 0:

curl -XGET http://localhost:9200/_cat/shards |\
  grep UNASSIGNED | grep ' r ' |\
  awk '{print $1}' |\
  xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
  -d '{ "index":{ "number_of_replicas": 0}}'

Вернем их к 1:

curl -XGET http://localhost:9200/_cat/shards |\
  awk '{print $1}' |\
  xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
  -d '{ "index":{ "number_of_replicas": 1}}'

Примечание. Не запускайте это, если у вас разные факторы репликации для разных индексов. Это жестко закодирует коэффициент репликации для всех индексов равным 1.

Это также может быть причиной дискового пространства. В Elasticsearch 7.5.2 по умолчанию, если использование диска превышает 85%, то шарды реплик не назначаются никакому другому узлу.

Это можно исправить, установив другой порог или отключив его в .yml или через Kibana.

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.threshold_enabled": "false"
  }
}

Сначала используйте API работоспособности кластера, чтобы получить текущее состояние кластера, где КРАСНЫЙ означает отсутствие одного или нескольких первичных сегментов, а желтый означает отсутствие одного или нескольких реплик.

После этого используйте API объяснения распределения кластера, чтобы узнать, почему отсутствует конкретный сегмент, а elasticsearch не может выделить его на узле данных.

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

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