Files
admin/.tasks/NEXT_SESSION.md
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.9 KiB
Raw Blame History

_last_updated_, session_id
_last_updated_ session_id
2026-05-28T16:30:00+03:00 2026-05-28-prod-epz-search-outage-admin-handoff

Next session handoff

Сессия: новая admin task restore-elasticsearch-indices-books-vds заведена по итогам диагностики prod outage в репозитории books.

Recent commits

  • (pending — этот сеанс ничего не commit'ил; .tasks/STATUS.md + .tasks/restore-elasticsearch-indices-books-vds.md + .tasks/NEXT_SESSION.md готовы к одному commit'у)

Контекст инцидента

В репо books сегодня диагностировали prod outage поиска slovo (товары + EPZ): /api/{epz,products}/search возвращают 500 index_not_found_exception. Эндпоинты лезут на canonical ES https://elasticsearch.kzntsv.site/ (books VDS Portainer stack 33) — и не находят там ни epz, ни products.

curl _cat/indices на двух сторонах:

  • elasticold.kzntsv.site (Windows rollback, live) — полный набор: epz 820604 / products 105922 / artmone 2621.
  • elasticsearch.kzntsv.site (books VDS stack 33) — 0 индексов, cluster green, 0 active primary shards. Даже read_me плейсхолдер из миграции 25.05 пропал.

Окно поломки: 27.05 10:24 MSK (последний рестарт books-api/books-web, ошибок в их stderr ещё не было) → 28.05 13:59 UTC (первая фиксация index_not_found_exception в логах). В этом окне на books VDS шла работа bookva-tenant-cutover-prep (Step 2 — 9 Portainer stacks создавались, в т.ч. bookva-es=37). Возможный конфликт volume/audit на stack 33 — выяснить forensics'ом.

Snapshot repo kreknin на target ES зарегистрирован (location=/snapshots). pre-migration-2026-05-25 снапшот был только с read_me placeholder, для restore не годится. Но в kreknin могут быть post-25.05 daily snapshots (books-vds-backup-daily-kreknin пайплайн closed 25.05) — проверить _snapshot/kreknin/_all?verbose=true, искать снимок с непустыми epz/products/artmone.

LIVE сейчас

  • books-app prod: поиск slovo (товары + EPZ) лежит, пользователи видят 500 на /epz/search. Заведена epz-search-seller-pin-tenant в books репо как side-issue (хардкод findByPk(1)), но не блокер этого outage'а.
  • Source ES на Windows host жив (elasticold.kzntsv.site через traefik basicAuth) — не disabled per migration policy, годится для повторного reindex.
  • Target ES на books VDS жив (cluster green, отвечает 200 на _cluster/health), но индексов нет.

Что делать на следующей сессии (по приоритету)

1. Forensics + restorerestore-elasticsearch-indices-books-vds

Полный playbook + acceptance в task-файле. Старт:

# на books VDS — Portainer audit stack 33
curl -fsS -H "X-API-Key: $PORTAINER_TOKEN" \
  https://portainer.kzntsv.site/api/stacks/33 | jq '.UpdateDate, .Status'
sudo docker volume inspect /usr/docker/elasticsearch/data
sudo ls -lah /usr/docker/elasticsearch/data/nodes/0/indices/ 2>/dev/null

Затем — curl _snapshot/kreknin/_all?verbose=true на target → если post-25.05 snapshot с непустыми индексами есть → restore. Иначе — reindex повторно по migrate-elasticsearch-to-books-vds.md Steps 46 (730MB, ~510 мин).

После — docker restart books-api books-web books-task-runner books-job-scheduler (на случай stale connection pool у consumer'ов).

2. (carried) Registry GC — ~20G storage reclaim

Из прошлого handoff'а, всё ещё pending. Read-only=true ~515 мин:

sudo docker exec registry registry garbage-collect --delete-untagged=true /etc/docker/registry/config.yml
sudo du -sh /opt/stacks/registry

3. (carried) Cleanup netplan artifacts — low priority, оставить

/etc/netplan/01-eth0.yaml, /etc/netplan/50-cloud-init.yaml, /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg — не влияют (netplan masked), оставить пока кто-нибудь не решит снять mask.

4. (carried) board-viewer-build unhealthy — пред-инцидент

Не связан с outage'ом. Опционально разобрать через sudo docker logs board-viewer-build | tail -50.

Спроси user'а

  • ES restore сейчас или подождать low-traffic окно? Reindex 730MB / 510 мин, slovo поиск всё это время уже лежит — задержка не критична для бэка, только для пользователей. Snapshot restore (если есть свежий) — быстрее.
  • Push wiki + memory + tasks — push'нуть commit'нутые изменения в origin? (Per project-discipline нужен per-session grant, пока не давал.)
  • Cleanup netplan artifacts — оставить или зачистить? (carried)

Не делать (preemptive guards)

  • НЕ stop / recreate Portainer stack 33 до forensics. Если volume накосячил из-за recreate — повторный recreate может затереть оставшиеся следы (logs, audit).
  • НЕ удалять kreknin repo / старые snapshot'ы до confirm'а что restore не нужен. pre-migration-2026-05-25 сам по себе не годится, но в repo могут лежать другие snapshots от daily пайплайна.
  • НЕ менять consumer config'и в books на elasticold обратно. На VPS bind-mount уже sed'нут на canonical с 25.05 — пусть остаётся. Восстановим данные на canonical endpoint'е, не двигаем endpoint.
  • НЕ unmask netplan/systemd-networkd на vds-kzntsv (carried — anti-pattern для Rusonyx).
  • НЕ reboot VDS без необходимости (carried).
  • НЕ делать registry GC без read-only=true (carried).

Memory updates за сессию

  • (нет новых memory-файлов — incident self-contained в task file с pointers на migration playbook)

Wiki ингест

  • (нет на этом раунде — после restore, если forensics выявит конкретный trigger «X recreate стирает Y volume», стоит ингестнуть в .wiki/concepts/portainer-stack-volume-pitfalls.md или подобное; пока гипотеза только)