livrare lot 2

backend/services/data-layer/didiDatabase/REBUILD.md

@@ -0,0 +1,63 @@
+# Rebuild bază de date pe alt host — rețetă
+
+## Ce e local vs derivat (important înainte de rebuild)
+
+| Store | Rol | Se seed-uiește? |
+|---|---|---|
+| **PostgreSQL** (`didi-postgres`, local pe didi11) | **sursă de adevăr** — 97 tabele, 4 scheme (bos_parammgmt, bos_analysis, bos_sysadmin, bos_subscriber) | **DA** — din dump-ul de mai jos |
+| **Redis** (`didi-cache`) chei `didi:config:*` + `didi:framework:*` | **cache derivat** din Postgres (populat de `sync-redis` din `component_config/prompt/stage_assignment`, `llm_model`, `moderation_*`) | **NU** — se regenerează cu `sync-redis` |
+| Redis `didi:pipeline:*` / `didi:queue:*` | stare runtime sesiuni (TTL) | NU — efemer |
+
+**Concluzie:** NU sunt date dublate în sensul de „două surse de adevăr". Seed-uiești
+DOAR Postgres; Redis se reface singur dintr-o comandă. Nu există fișier de seed
+pentru Redis și nici nu e nevoie.
+
+## Fișierul de seed
+
+`DIDI_full_export_2026-07-02.sql` (23 MB) — pg_dump complet: schema + date + toate
+migrațiile (inclusiv 016 input_type_profile_version, 017 model catalog attributes).
+Restorabil (`--clean --if-exists --no-owner`). Validat: restore curat pe Postgres
+gol → 99 tabele, date reale (23 modele LLM, 83 stage assignments, 6 profiluri).
+
+> Seed-ul vechi `DIDI_full_export_2026-03-22.sql` (fără migrațiile 016/017) și pachetul
+> demo (`DIDI_demo_seed_2026-07-02.sql` + `demo-seed/`) au fost arhivate în afara repo-ului
+> (`/home/admin365/didi_seed_archive_2026-07-08/`) — livrarea folosește DOAR full seed-ul curent.
+
+## Pași rebuild
+
+```bash
+# 1. Pornește un Postgres (local container SAU clusterul extern — vezi mai jos)
+#    Aici: containerul local, ca pe didi11.
+docker compose -f services/data-layer/docker-compose.local.yml up -d didi-postgres
+until docker exec didi-postgres pg_isready -U bos_interface; do sleep 2; done
+
+# 2. Restaurează schema + datele
+docker exec -i didi-postgres psql -U bos_interface -d DIDI \
+  < services/data-layer/didiDatabase/DIDI_full_export_2026-07-02.sql
+# (un singur warning benign 'transaction_timeout' pe versiuni PG <17 — se ignoră)
+
+# 3. Pornește restul serviciilor (agent-v3, framework, workeri) — se conectează
+#    la didi-postgres prin PG_HOST/DB_HOST din compose.
+cd services/orchestration-layer/agent-v3 && docker compose up -d
+cd ../didiFramework && docker compose up -d didi-framework
+
+# 4. Regenerează cache-ul Redis din Postgres (config + framework params)
+docker exec didi-framework sh -c 'wget -qO- --post-data="" http://127.0.0.1:3005/api/sync-redis'
+
+# 5. (verificare) Redis populat + un răspuns 200 pe framework
+docker exec didi-cache redis-cli -a redis123 --no-auth-warning dbsize
+curl -sf http://localhost:3005/health
+```
+
+## Local vs cluster extern
+
+Serviciile sunt agnostice — `PG_HOST`/`DB_HOST` din compose decid ținta:
+- **didi11 (acum):** `didi-postgres` (container local, 5432).
+- **Producție/cluster:** setează `PG_HOST=10.11.50.167 PG_PORT=5000` (VIP Patroni/HAProxy).
+Același dump se restaurează în oricare; la cluster, restaurează pe leaderul RW (`:5000`).
+
+## HA opțional
+
+Dacă vrei Postgres HA pe noul host (nu single-node), vezi
+`ha-cluster/` (Patroni + etcd + HAProxy) — restaurează dump-ul pe `:5000` după
+`patronictl list` arată un leader.