Всем привет, меня зовут Илья и я хочу вам рассказать как я после небольшой правки в тераформ потерял все мастера в кластере Elasticsearch. ЧатГПТ и гугл уже принесли мне лопату чтобы похоронить эти сервера, но начальство сказало: "Может что-нибудь придумаешь?". В итоге 6 часов работ и кластер снова живой и зеленый. Хотите знать больше?

Подготовка идеального плана

Начиналось всё довольно просто, обычное обновление кластера с 7 до 8 версии, который настроен совершенно не так как все остальные ибо так дешевле.
Но архитектура кластера была нетипичной. Обычно мы обновляли Elasticsearch на bare metal по стандартной схеме, но в AWS решили сэкономить.
Помимо обновления Elasticsearch с 7 на 8 версию требовалось заменить AMI. Это означало полный редеплой серверов с изменением IP-адресов.

План казался безупречным:

• поднять новые master-ноды на новой AMI;

• вывести часть старых мастеров;

• обновить data-ноды;

• завершить миграцию мастеров.

На бумаге всё выглядело красиво.

Время краха

После завершения работ кластер выглядел здоровым. Все ноды были в строю, ошибок не наблюдалось.
Я спокойно пошёл забирать детей из школы.
Это была ошибка.

Интрига, скандал расследование! Что, как, почему?
Но в логах мастеров я видел ошибку:

[2026-06-01T18:12:06,719][WARN ][o.e.c.c.ClusterFormationFailureHelper] [host2-master] master not discovered or elected yet, an election requires at least 3 nodes with ids from [Uiwsdq-5TFe4tHneOZWMkg, mo_qkfqyRuOj4qCWx1z2GQ, 1lGkgLjbTYa-n-ueZK2Vyg, 6K-pbaclRiCeLolL4FsXRg, zMIk1gy_TwakVizlY849wQ], have only discovered non-quorum [{host1-master}{zMIk1gy_TwakVizlY849wQ}{YnAUqCJpQWajdU6D5oJhHA}{1.1.1.1}{1.1.1.1:9300}{m}, {host1-master}{wUTUT27tShurgAxaPPOR2A}{Lm1QZHScRTyUYlBzGUktXg}{3.3.3.3}{3.3.3.3:9300}{m}, {host3-master}{mo_qkfqyRuOj4qCWx1z2GQ}{gZhsE5rpSEqXvWCvVhQ8hw}{2.2.2.2}{2.2.2.2:9300}{m}]; discovery will continue using [2.2.2.2:9300, 3.3.3.3:9300] from hosts providers and [{host2-master}{zMIk1gy_TwakVizlY849wQ}{YnAUqCJpQWajdU6D5oJhHA}{1.1.1.1}{1.1.1.1:9300}{m}] from last-known cluster state; node term 2618, last-accepted version 11377643 in term 2618

Кворум потерян и мастеров с данными у меня больше нет чтобы его собрать. Почему метаданные не переехали на новые мастера мне выяснить не удалось. Но лужа от пота(смотри мем выше) подо мной уже стала гигантской.
И тут я вспомнил что на одной конференции по еластиксеарч умные дяди мне задавали подобную задачку как восстановить кластер без мастеров. Правильный ответ тогда был никак, мол они все уже перепробовали и у них не получилось.
Гугл и ИИ мне говорили тоже самое, мол не переживай просто разверни из бэкапа. Ты же делал бэкап? ?

Мы как то пробовали сделать бэкап, бэкап некскольких сот террабайт данных длился дольше актуальности данных. Больше мы подобным не занимаемся.

Поиск собственного пути

Что я имел одна нода со старыми метаданными + 2 мастер ноды которые не имели нужные для кластера данные. Из трех мастер-нод одна физически осталась жива, но кворум уже был потерян. Для Elasticsearch это практически равнозначно потере всех мастеров, потому что кластерное состояние восстановить было невозможно.
Первым делом я решил не трогать единственную ноду с методанными и попробовать поколдавать с новыми мастерами чтобы они подключились к кластеру.
Что я пробовал:
Пробовал копировать метаданные с рабочей ноды.
Пробовал менять id на тот которые требовался в метаданных.
Но у меня ничего не получилось, если у вас ещё варианты что можно было попробовать буду рад узнать.

В документации написано что можно попробовать остановить все ноды и запустить ноду с данными вот так.

/usr/share/elasticsearch/bin/elasticsearch-node unsafe-bootstrap

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

Осознание

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

Инструкция по восстановлению

Сначала был поднят абсолютно новый чистый кластер Elasticsearch.
После этого нужно вернуть все датаноды в кластер.
Старые данные и metadata временно убирались:

mv /data/nodes{,.back}

Нода запускалась уже как чистая:

systemctl restart elasticsearch

После появления в кластере, проверить можно так:

curl localhost:9200/_cat/nodes?v

нода останавливалась:

systemctl stop elasticsearch

Теперь самое интересное.

Из старого data path возвращались только данные индексов:

mv /data/nodes.back/0/indices/* /data/nodes/0/indices/

Без metadata кластера.

После чего нода запускалась снова:

systemctl restart elasticsearch

После запуска Elasticsearch обнаруживал локальные shard-данные, для которых не существовало записей в cluster state.
Индекс автоматически переходил в состояние dangling index.
Проверить это можно было так:

curl localhost:9200/_dangling

В ответ появлялись UUID индексов.

Получалось примерно следующее:

{
"index_name": "orders",
"index_uuid": "abc123"
}

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

Самое время запускать трехстрочный однострочник и пойти жевать бамбук!

Скрипт:

После выполнения Elasticsearch начал импортировать найденные индексы обратно в cluster state.

curl -s 'http://localhost:9200/_dangling' |
jq |
grep index_uuid |
cut -d '"' -f 4 |
while read i; do
    echo "$i"
    curl \
      "http://localhost:9200/_dangling/$i?accept_data_loss=true&pretty" \
      -XPOST
    echo "$i done"
done

Всего 3 часа на восстановление после запуска скрипта, чуть больше 2к шард были восстановлены и кластер стал зеленым.

Итого

В результате удалось:

• поднять новый кластер;

• подключить существующие data-ноды с данными на них;

• обнаружить dangling indices и вернуть их в кластер;

• не использовать бэкапы

При этом:

• cluster UUID стал новым;

• старое cluster state восстановить не удалось, а это значит что все настройки кластера и шаблоны пришлось создавать заново.

Но сами данные удалось спасти.

Если у вас есть более простые способы я был бы рад их услышать. Надеюсь, этот опыт больше никогда не пригодится.Хотя впереди у меня ещё несколько обновлений Elasticsearch, поэтому зарекаться не буду.