Files

vitya e9b0a9edbc docs(tasks): restore-elasticsearch-indices-books-vds — books VDS ES stack 33 пуст

Prod incident в репо books: slovo поиск товаров+EPZ лежит. `elasticsearch.kzntsv.site`
отвечает 200 на _cluster/health (green, 0 active shards, 0 docs); source
`elasticold.kzntsv.site` (Windows rollback) — полный набор: epz 820604 /
products 105922 / artmone 2621. Окно поломки 27.05 10:24 → 28.05 13:59, в нём
шла bookva-tenant-cutover-prep (bookva-es stack 37 создавался) — возможный
конфликт.

Playbook в task-файле: forensics (Portainer stack 33 audit + docker volume
inspect) → snapshot restore из kreknin repo если post-25.05 snapshot с
непустыми индексами → иначе reindex повторно по migrate-elasticsearch-to-books-vds
procedure (730MB ~5-10 мин). После — restart 4 consumer'ов.

NEXT_SESSION.md перезаписан, restore поставлен как приоритет 1, carried
items (registry GC, netplan artifacts, board-viewer-build) сохранены.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-28 19:50:13 +03:00

6.6 KiB

Raw Blame History

restore-elasticsearch-indices-books-vds

Goal

Восстановить 3 ES индекса (epz, products, artmone) на canonical endpoint elasticsearch.kzntsv.site (books VDS, Portainer stack 33). Сейчас target ES пустой → весь поиск в books-app (slovo) сломан (404 index_not_found_exception для epz и products).

Симптомы (зафиксировано 2026-05-28 ~15:50 MSK)

bookva.kzntsv.site/api/products/search?q=... → 500 no such index [products].
bookva.kzntsv.site/api/epz/search?q=... → 500 no such index [epz].
books-api + books-web логи (stderr) — десятки ResponseError: index_not_found_exception за час.
User-facing impact: страница /epz/search и поиск товаров в slovo UI не работают.

Текущее состояние ES endpoint'ов

Source (Windows host, rollback — не выключен): https://elasticold.kzntsv.site/

index    health docs.count store.size
artmone  yellow       2621      1.4mb
epz      yellow     820604    699.7mb
products yellow     105922     26.6mb

Проверено curl -u books:<pw> https://elasticold.kzntsv.site/_cat/indices.

Target (books VDS, Portainer stack 33, canonical): https://elasticsearch.kzntsv.site/

_cluster/health: status=green, active_primary_shards=0, docs=0
_cat/indices:    (пусто, ни одного индекса)
_snapshot/_all:  kreknin fs repo зарегистрирован (location=/snapshots)

ES жив, отвечает 200 на _cluster/health, basicAuth работает. Но индексов нет вообще — даже placeholder read_me из 25.05 исчез. Значит volume был стёрт ИЛИ контейнер recreate'нут с пустым томом между 25.05 (migration complete, smoke green) и 28.05.

Когда сломалось

2026-05-25: migrate-elasticsearch-to-books-vds closed. Все 3 индекса reindex'нуты с elasticold на books VDS, consumer configs sed'd elasticold → elasticsearch, smoke green.
2026-05-27 10:24 MSK: books-api / books-web рестартовали (текущий uptime 29h). Это до появления ошибок — значит ES опустел уже после рестарта, иначе они бы залогировали 404 сразу.
2026-05-28 13:59 MSK (по UTC в логах) — самая ранняя зафиксированная ошибка no such index [epz]. Окно поломки: 27.05 10:24 → 28.05 13:59.
В этом окне на books VDS происходила работа bookva-tenant-cutover-prep (Step 2 — 9 Portainer stacks created, в т.ч. bookva-es=37). Возможная гипотеза — конфликт volume mount'а или случайный delete на slovo ES при подготовке bookva ES. Точная причина — детектить надо на VDS (Portainer audit log + volume listing + container restart history).

Pointers

Migration task (canonical процедура reindex-from-remote с elasticold на books VDS): migrate-elasticsearch-to-books-vds.md — playbook применим повторно как есть.
Frozen mappings/settings: .scratch/source-mappings.json + .scratch/source-settings.json (от 2026-05-25, source структура не менялась — проверить на свежесть до reindex).
Snapshot repo на books VDS: kreknin (/snapshots). Snapshot pre-migration-2026-05-25 содержал только read_me placeholder — не годится для восстановления (предмиграционный, до reindex). Полезным может быть kreknin daily snapshot после 25.05 если он сохранил полные индексы.
Consumer configs: уже указывают на elasticsearch.kzntsv.site (sed 25.05). После восстановления — никаких config changes, только рестарт consumers (на случай stale connection pool).

Acceptance

curl -u books:<pw> https://elasticsearch.kzntsv.site/_cat/indices показывает 3 индекса (epz/products/artmone) с doc counts ≈ source: 820604 / 105922 / 2621 (±несколько на дельту со source).
books-api + books-web stderr за 5 минут после рестарта — 0 строк index_not_found_exception.
Smoke: https://bookva.kzntsv.site/api/epz/search?q=пушкин&... → 200 с непустым rows.
Source elasticold.kzntsv.site остаётся live (rollback policy не меняется, как было при оригинальной миграции).

Подходы (выбрать на месте)

Reindex повторно — точно та же процедура что 25.05 (см. migrate-elasticsearch-to-books-vds.md Steps 4–6). 730MB, ~5-10 мин. Source доступен и полный.
Snapshot restore — если в kreknin repo есть свежий snapshot (после 25.05) с непустым epz/products/artmone. Проверить _snapshot/kreknin/_all?verbose=true. Быстрее reindex'а, если есть.
Volume forensics — параллельно (или до восстановления) посмотреть Portainer stack 33 history + docker volume inspect /usr/docker/elasticsearch/data + audit log в Portainer когда менялся stack. Цель — понять что произошло, чтобы оно не повторилось после bookva cutover.

Recommendation: начать с (3) для understanding root cause, дальше (2) если snapshot есть, иначе (1).

Branch

n/a (admin ops)

Status

ready

Where I stopped

(not started — created 2026-05-28 ~16:00 MSK by vitya@books session после диагностики prod-инцидента)

Next action

См. секцию «Подходы» — старт с volume forensics (Portainer stack 33 history + docker volume inspect), параллельно проверить _snapshot/kreknin/_all на наличие post-25.05 snapshot'ов с непустыми индексами. Дальше выбрать между snapshot restore и reindex repeat. Восстановить → smoke от bookva.kzntsv.site/api/epz/search.

6.6 KiB Raw Blame History Unescape Escape