Атомная подстановка псевдонимов завершается с index_not_found_exception для полностью несвязанного индекса

Question

Я хочу заменить и индексировать с нулевым временем простоя, как описано в документации ES.

Я делаю это путем:

• создание нового индекса my_index_v2 с новыми данными
• Обновление нового индекса
• затем обменять их в атомарной операции, выполнив следующий запрос:

POST /_aliases

{
    "actions": [
        { "remove": { "index": "*", "alias": "my_index" }},
        { "add":    { "index": "my_index_v2", "alias": "my_index" }}
    ]
}

Это работает, как и ожидалось, за исключением случаев, когда случайным образом происходит сбой с ответом 404. Сообщение об ошибке:

{
   "error": {
      "root_cause": ... (same)
      "type": "index_not_found_exception",
      "reason": "no such index",
      "resource.type": "index_or_alias",
      "resource.id": "my_unrelated_index_v13",
      "index": "my_unrelated_index_v13"
   },
   "status": 404
}

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

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

Есть ли причина, по которой эти операции мешали бы друг другу? Что здесь происходит?

РЕДАКТИРОВАТЬ: уточнил шаг УДАЛИТЬ в конце.

Answer 1

Это трудно воспроизвести в локальной среде, потому что это происходит только в высокопараллельных сценариях. Однако... как отметил @Eirini Graonidou в комментариях, это действительно похоже на ошибку ES, исправленную в PR 23153.

Из запроса на вытягивание (выделено мной):

Это либо приводит к загадочным ответам, когда в Elasticsearch отправляется неверный запрос (если индекс с именем «плохой-запрос» не существует, он создает исключение «индекс не найден» и в противном случае отвечает настройками индекса для индекса с именем «плохой-запрос»). ").

Это не объясняет ситуацию с "плохим запросом", но определенно объясняет, почему сообщение об ошибке не имеет смысла.

Что еще более важно: обновление elasticsearch решает эту проблему.