# 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`](migrate-elasticsearch-to-books-vds.md) 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](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 не меняется, как было при оригинальной миграции).

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

1. **Reindex повторно** — точно та же процедура что 25.05 (см. migrate-elasticsearch-to-books-vds.md Steps 4–6). 730MB, ~5-10 мин. Source доступен и полный.
2. **Snapshot restore** — если в `kreknin` repo есть свежий snapshot (после 25.05) с непустым `epz`/`products`/`artmone`. Проверить `_snapshot/kreknin/_all?verbose=true`. Быстрее reindex'а, если есть.
3. **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`.

<!-- created-by: vitya@books-session / 2026-05-28 / trigger: prod slovo поиск товаров+EPZ сломан, ES indices пусты на canonical endpoint -->