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

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

3.2 KiB Raw Blame History