Желтый статус означает, что один или несколько шардов-реплик в кластере OpenSearch не выделены узлу. Не стоит паниковать! Существует несколько причин, по которым желтый статус может быть совершенно нормальным, и во многих случаях OpenSearch сам восстановится до зеленого, так что хуже всего начинать что-то настраивать, не зная точно, в чем причина. Пока статус желтый, операции поиска и индексирования по-прежнему доступны.
Как решить проблему
Почему кластер OpenSearch показывает желтый статус?
Существует несколько причин, по которым кластер OpenSearch может показывать желтый статус:
- У вас только 1 узел
- Вы перезапустили узел
- Произошел сбой узла
- Проблемы с сетью
- Проблемы с дисковым пространством
- Осведомленность о распределении узлов
- Шард превысил максимальное количество повторных попыток
У вас только 1 узел
(Или количество реплик >= количество узлов)
OpenSearch никогда не назначит реплику на тот же узел, что и основной шард, поэтому если у вас только один узел, то вполне нормально и ожидаемо, что ваш кластер будет отображаться желтым цветом. Если вам удобнее, чтобы он был зеленым, то измените число реплик для каждого индекса на 0.
| 1 2 3 4 5 6 | PUT /my-index/_settings { "index" : { "number_of_replicas" : 0 } } |
Аналогично, если количество реплик равно или превышает количество узлов, то выделение одного или нескольких шардов будет невозможно по той же причине.
Вы перезапустили узел
Если Вы временно перезапустили узел, то обычно никаких действий предпринимать не нужно, так как OpenSearch автоматически восстановит шарды и вернется к зеленому состоянию. Вы можете проследить за этим процессом, вызвав команду:
| 1 | GET _cluster/health |
И вы увидите, что количество нераспределенных шардов постепенно уменьшается, пока не будет достигнут зеленый статус.
Однако если вы видите, что этот процесс повторяется, значит, какая-то другая проблема вызывает нестабильность кластера и требует расследования.
Сбои в работе узлов
Если узлы перегружены или перестают работать по какой-либо причине, то первым симптомом, вероятно, будет то, что узлы становятся желтыми или красными, поскольку шарды не синхронизируются. Узлы могут отключаться из-за длительных пауз в работе GC, возникающих из-за ошибок "out of memory" или высокого спроса на память в результате интенсивного поиска.
Сетевые проблемы
Если узлы не могут надежно связаться друг с другом, то они теряют связь друг с другом и происходит рассинхронизация шардов, что приводит к появлению красного или желтого статуса. Обнаружить такую ситуацию можно, обнаружив в журналах повторяющиеся сообщения о выходе или возвращении узлов из кластера.
Проблемы с дисковым пространством
Недостаток дискового пространства может помешать OpenSearch выделить шард узлу. Обычно это происходит, когда загрузка диска превышает указанное ниже значение:
| 1 | cluster.routing.allocation.disk.watermark.low |
В этом случае для решения проблемы необходимо удалить индексы, увеличить размер диска или добавить новый узел в кластер. Конечно, можно временно увеличить водяной знак, чтобы поддержать работу, пока вы решаете, что делать, но просто откладывать решение на потом - не лучший вариант.
| 1 2 3 4 5 6 7 | PUT _cluster/settings { "transient": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.info.update.interval": "1m" } } |
Вы также можете получить:
| 1 | cannot allocate because allocation is not allowed to any of the nodes |
Обычно это происходит, когда загрузка диска узла превышает уровень заполнения, создавая блок записи на кластере. Как и выше, необходимо удалить данные или добавить новый узел. Вы можете выиграть время с помощью:
| 1 2 3 4 5 6 7 8 | PUT _cluster/settings { "transient": { "cluster.routing.allocation.disk.watermark.flood_stage": "97%", "cluster.info.update.interval": "1m" } } |
Осведомленность о распределении узлов
Иногда в правилах распределения, созданных на кластере, могут возникать специфические проблемы, не позволяющие кластеру распределять шарды. Например, можно создать правила, требующие, чтобы реплики шарда были распределены по определенному набору узлов (информированность о распределении), таких как зоны доступности или различные хост-машины в системе kubernetes. В некоторых случаях эти правила могут вступать в конфликт с другими правилами (например, дискового пространства) и препятствовать выделению шардов.
Шард превысил максимальное количество повторных попыток
Если ошибка содержит: "шард превысил максимальное количество повторных попыток [5] при неудачных попытках выделения - вручную вызовите [/_cluster/reroute?retry_failed=true] для повторной попытки", необходимо выполнить повторную попытку выделения, используя:
| 1 | curl -XPOST localhost:9200/_cluster/reroute?retry_failed |
Поиск причины невыделения
Для этого можно использовать API распределения кластера:
| 1 | GET /_cluster/allocation/explain |
Выполнив приведенную выше команду, вы получите объяснение статуса выделения первого найденного нераспределенного шарда.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | { "index" : "my_index", "shard" : 0, "primary" : false, "current_state" : "unassigned", "unassigned_info" : { "reason" : "NODE_LEFT", "at" : "2017-01-04T18:53:59.498Z", "details" : "node_left[G92ZwuuaRY-9n8_tc-IzEg]", "last_allocation_status" : "no_attempt" }, "can_allocate" : "allocation_delayed", "allocate_explanation" : "cannot allocate because the cluster is still waiting 59.8s for the departed node holding a replica to rejoin, despite being allowed to allocate the shard to at least one other node", "configured_delay" : "1m", "configured_delay_in_millis" : 60000, "remaining_delay" : "59.8s", "remaining_delay_in_millis" : 59824, "node_allocation_decisions" : [ { "node_id" : "pmnHu_ooQWCPEFobZGbpWw", "node_name" : "node_t2", "transport_address" : "127.0.0.1:9402", "node_decision" : "yes" }, { "node_id" : "3sULLVJrRneSg0EfBB-2Ew", "node_name" : "node_t0", "transport_address" : "127.0.0.1:9400", "node_decision" : "no", "store" : { "matching_size" : "4.2kb", "matching_size_in_bytes" : 4325 }, "deciders" : [ { "decider" : "same_shard", "decision" : "NO", "explanation" : "the shard cannot be allocated to the same node on which a copy of the shard already exists [[my_index][0], node[3sULLVJrRneSg0EfBB-2Ew], [P], s[STARTED], a[id=eV9P8BN1QPqRc3B4PLx6cg]]" } ] } ] } |
Приведенный выше api возвращает :
- "unassigned_info" => Причина, по которой шард стал не назначенным.
- "node_allocation_decision" => Список объяснений для каждого узла, объясняющих, может ли он потенциально получить шард.
- "deciders" => Решение и объяснение этого решения.