🐘 2) Stratégie d’architecture

Objectif : définir le socle d’architecture PostgreSQL (connexions, pooling, stockage, HA/backup/monitoring) en fonction du profil collecté en étape 1.

2.1

Connexions & pooling

PgBouncer (transaction/session) pour maintenir un max_connections faible côté PG, absorber les pics et éviter l’explosion de work_mem.

pgbouncer.ini max_connections 50–200

2.2

Layout stockage

Séparation (DATA / WAL / temp) quand possible. NVMe pour WAL/temp. RAID10 & XFS/ext4 tunés, noatime, alignement RAID.

DATA / WAL / TEMP RAID10

2.3

HA, sauvegardes, observabilité

pgBackRest/Barman pour sauvegardes base+WAL, réplication streaming (async/sync), slots dimensionnés, exporter Prometheus.

pgBackRest Prometheus exporter

2.1 Connexions & pooling

Objectif

Empêcher PostgreSQL d’avoir 500–1000 connexions actives qui explosent la mémoire et les LWLocks. On garde PG à 50–200 connexions max, et on laisse PgBouncer absorber les pics.

Mode PgBouncer

Mode	Usage
transaction	OLTP, web, Django, services courts
session	Outils, reporting, clients lourds
statement (rare)	Tests, cas spécifiques

Paramètres PG cibles

max_connections = 100 (ou même 50) → le pool fait le reste
work_mem dimensionné sur 100 connexions et pas 1000
max_worker_processes, max_parallel_workers_per_gather alignés sur CPU

Exemple pgbouncer.ini

[databases]
myapp = host=127.0.0.1 port=5432 dbname=myapp

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = md5
pool_mode = transaction       ; ou 'session'
max_client_conn = 1000        ; ce que les apps voient
default_pool_size = 50        ; ce que PG voit
reserve_pool_size = 10
server_reset_query = DISCARD ALL

À surveiller

Connexions longues (ETL, migrations) → basculer en mode session
Pool saturé → augmenter default_pool_size ou mettre plusieurs pools
Sur cloud/VM → vérifier latence entre bouncer et PG

2.2 Layout stockage

Principe

Protéger les WAL (écrits très souvent) et les fichiers temporaires des I/O aléatoires du DATA.

Séparation recommandée

Zone	Recommandations
DATA	RAID10, XFS/ext4, noatime, cache contrôlé
WAL	NVMe dédié ou RAID1 rapide, FUA/BBU ok
TEMP	NVMe/SSD rapide, même serveur ou volume élastique

FS & montage

XFS souvent très bon par défaut
ext4 avec noatime, barrier=1 selon contrôleur
Alignement RAID : stripe/stride cohérent avec le contrôleur

Commandes / checks

# voir les disques / FS
lsblk -o NAME,ROTA,SIZE,MODEL,MOUNTPOINT,FSTYPE
mount | egrep 'xfs|ext4'

# scheduler
cat /sys/block/nvme0n1/queue/scheduler

# io-depth, latence (fio)
fio --name=randrw --filename=/pgtmp/fio.test --rw=randrw \
    --bs=4k --iodepth=32 --size=1G --runtime=60 --numjobs=4 --group_reporting

À éviter

RAID5/6 pour OLTP write-heavy (latence)
Cache contrôleur non protégé
Mélanger DATA et WAL sur disques lents

2.3 HA, sauvegardes, observabilité

Sauvegardes

Outil recommandé : pgBackRest (chiffrage, compression, rotation, vérif)
Sauvegarde base + archives WAL
Test de restauration automatisé (pas juste backup !)

Réplication

Mode	Usage
Streaming async	par défaut, impact faible sur latence
Streaming sync	durabilité ++, mais impact direct sur latence
Slots logiques	ETL, CDC, mais surveiller la rétention WAL

Observabilité

pg_stat_statements activé
pg_stat_io (PG ≥ 15)
Exporter Prometheus (postgres_exporter, node_exporter)
Dashboards Grafana (WAL, checkpoints, autovacuum)

# vérifier la réplication
SELECT * FROM pg_stat_replication;

# slots (à surveiller)
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots;

Points de décision

RPO=0 → réplication sync + infra rapide
RTO court → patron Patroni/Patroni-like + VIP/LoadBalancer
Cloud → regarder services managés (failover natif)