# 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.