Runbook : base de données saturée

Latence qui explose, connexions refusées, espace disque rempli. Comment diagnostiquer et corriger.

Symptômes

  • Latence p99 multipliée par 10 du jour au lendemain
  • Erreurs too many connections ou could not connect
  • Erreurs could not extend file ou no space left on device
  • CPU constamment à 100 % sur l'addon

Diagnostiquer

$ paas addons:metrics db-12345 --since 1h
# CPU, RAM, IO, connexions ouvertes, taille

$ paas addons:slow-queries db-12345 --top 10
# 10 requêtes les plus lentes des dernières 24h

Trop de connexions

FATAL: too many connections for role "user"

Votre app ouvre trop de connexions. Solutions :

  • Connection pooling côté app (PgBouncer en sidecar, ou pool natif de votre ORM)
  • Augmenter le plan : plus de RAM = plus de connexions autorisées
  • Réduire les workers : si vous avez 50 workers, chacun ouvre quelques connexions, ça grimpe vite

Requêtes lentes

L'agent DBA, s'il est activé, a déjà repéré les slow queries et propose des index. Sinon :

$ paas addons:psql db-12345
postgres=# SELECT query, mean_exec_time, calls FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;

Espace disque saturé

no space left on device
  • Vérifier la taille : paas addons:info db-12345
  • VACUUM FULL sur les grosses tables après suppression massive
  • Upgrader le plan : paas addons:upgrade db-12345 postgres-pro-large
  • Archiver les vieilles données sur S3 et truncate

Upgrader sans downtime

Sur les plans Pro et Entreprise, l'upgrade se fait sans downtime grâce à la réplication primaire/secondaire :

$ paas addons:upgrade db-12345 postgres-pro-large --app monsite
# bascule transparente du primary, durée typique : 90 s

L'agent DBA

Pour ne plus avoir ce genre de surprise : activez l'agent DBA (plan Pro). Il surveille en continu et propose des optimisations avant que vous ayez un incident.