PostgreSQL — pe cluster Patroni HA (status curent)

TL;DR: DIDI folosește clusterul Patroni extern (3 noduri PG + 3 etcd + 2 HAProxy LB). Containerul local staging-dataLayer-postgres din data-layer/docker-compose.yml păstrează doar tabelul waitlist — toate datele de business sunt pe cluster.

Ce era aici (legacy)

Cândva, staging-dataLayer-postgres (Postgres 15 Alpine, container Docker) servea toate datele DIDI. Avea ~22 tabele în schemele analyses, catalog, execution, pipelines, users — toate din vechiul orchestrator Python. Acum sunt goale, nefolosite, schema veche arhivată în /home/admin365/old_deprecated_code_archive/didiDatabase-legacy/.

Ce e acum

Cluster Patroni (productie)

Componentă	Hostname	IP	Port	Rol
pg-node1	`pg-node1-test`	`10.11.50.160`	5432	Replica streaming
pg-node2	`pg-node2-test`	`10.11.50.161`	5432	Replica streaming
pg-node3	`pg-node3-test`	`10.11.50.162`	5432	Leader curent
etcd-node1/2/3	—	`10.11.50.163-165`	2379	Quorum
HAProxy LB1	`haproxy-lb-test`	`10.11.50.166`	5000 (RW), 5001 (RO)	Primary
HAProxy LB2	`haproxy-lb2-test`	`10.11.50.169`	5000, 5001	Secondary
pgBackRest	`pg-backup-test`	`10.11.50.168`	—	Backup zilnic + NFS

Endpoint-uri pentru aplicații DIDI:

Scop	Endpoint	Notă
WRITE (orice modificare)	`10.11.50.167:5000`	DIDI configurat aici (HAProxy LB)
READ (raportări)	`10.11.50.167:5001`	replica load-balanced

.166, .167 și .169 sunt toate HAProxy LB valide spre același cluster Patroni. DIDI folosește .167 istoric. Verificat 2026-04-28: toate trei dau aceleași date (1782 sesiuni).

Database principal: `DIDI`

User: bos_interface / parolă în vault-ul de credențiale name='PostgreSQL Cluster Patroni (admin)'.

4 scheme + public:

bos_analysis (6 tabele + view) — scrise de agent-v3
bos_parammgmt (~40 tabele) — scrise de didiFramework, sincronizate în Redis
bos_sysadmin (5 tabele) — utilizatori, credite, abonamente
bos_subscriber (4 tabele) — date personale
public.waitlist — pe containerul local, nu cluster

Database-uri suplimentare pe același cluster

kong_db (user kong) — folosit de Kong cluster (vezi gateway-auth-layer/didiKong/MIGRATION.md)
keycloak_db (user keycloak) — folosit de Keycloak

Ce mai e local (containerul `staging-dataLayer-postgres`)

Definit în data-layer/docker-compose.yml. Nu e pe rețea externă — doar Docker network. Singurul tabel activ: public.waitlist în DB misinformation_db (3 înregistrări).

Folosit doar de didiFramework/src/routes/waitlist.ts prin pool separat (stagingPool cu host staging-dataLayer-postgres).

Schemele legacy (analyses, catalog, etc.) sunt goale.

De ce nu am migrat waitlist pe cluster?

Decizie pragmatică: waitlist e public-facing (anyone-can-signup), volum mic, nu necesită HA. Containerul local e suficient. Migrare ulterioară opțională.

Connection patterns în cod

// agent-v3/src/shared/persistence/pg-pool.ts
host: '10.11.50.167', port: 5000, database: 'DIDI', user: 'bos_interface'

// didiFramework/src/config/database.ts (production data)
host: '10.11.50.167', port: 5000, database: 'DIDI'

// didiFramework/src/routes/waitlist.ts (special — local container)
host: 'staging-dataLayer-postgres', port: 5432, database: 'misinformation_db'

Verificare connectivity

# Cu psql container (din host)
docker run --rm --network host -e PGPASSWORD=<pwd> postgres:15-alpine \
  psql -h 10.11.50.167 -p 5000 -U bos_interface -d DIDI \
  -c "SELECT inet_server_addr() AS leader, now()"

# Patroni REST API status
curl -s http://10.11.50.162:8008/cluster | python3 -m json.tool

Backup

pgBackRest zilnic (full săptămânal + incremental zilnic) pe 10.11.50.168 cu storage NFS la 10.11.10.150. Toate DB-urile DIDI intră automat în stanza globală — nu trebuie config per-app.

Linkuri rapide

Ghid utilizare cluster: landingzone/postgres-patroni/README.md (repo git.finesynergy.eu/lucian/landingzone)
Onboarding aplicație nouă: landingzone/postgres-patroni/CLAUDE_PROMPT.md
HAProxy stats: http://10.11.50.166:7000/stats

Status

✅ Migrare făcută înaintea acestui mono-repo (cluster Patroni e canonical)
✅ Container local păstrat doar pentru waitlist
⚠️ DIDI configurat pe HAProxy LB .167 (canonical landingzone e .166); ambele rutează la același leader — schimbare cosmetică opțională

4.6 KiB Raw Blame History