</>
Plan du cours — 49/64

Superviser une base en production

Avancé

Les incidents PostgreSQL se lisent dans quelques vues système : savoir où regarder fait gagner des heures.

Qui fait quoi maintenant ?#

SELECT pid, usename, state, wait_event_type, wait_event,
       now() - query_start AS duree, left(query, 80) AS requete
FROM   pg_stat_activity
WHERE  state <> 'idle' AND pid <> pg_backend_pid()
ORDER  BY duree DESC;

SELECT pg_cancel_backend(1234);       -- annule la requête en cours (douce)
SELECT pg_terminate_backend(1234);    -- ferme la connexion (dure)

Les indicateurs à surveiller#

IndicateurSignal d'alerte
Connexions actives / max_connectionsSaturation ; ajoutez un pooleur
Ratio de cache (blks_hit / (blks_hit + blks_read))Bien en dessous de 99 % : shared_buffers ou RAM insuffisants
Transactions les plus longues, idle in transactionBlocage du VACUUM, verrous retenus
Retard de réplicationLectures obsolètes, risque de perte à la bascule
Lignes mortes / dernière exécution d'autovacuumBloat en formation
Espace disque et croissance du WALUn slot de réplication oublié peut remplir le disque
Verrous en attente (pg_locks)Migration ou transaction bloquante

Outils#

  • pg_stat_statements : les requêtes coupables.
  • Prometheus + postgres_exporter + Grafana, ou le monitoring de votre fournisseur cloud.
  • pgBadger : analyse des journaux de requêtes lentes.
  • Alertes sur le retard de réplication, l'espace disque, les connexions et le taux d'erreurs.

Astuce : notez dans un runbook les 5 requêtes de diagnostic ci-dessus. Pendant un incident à 3 h du matin, on ne veut pas les réinventer.

← Leçon précédenteMigrations en ligne sans interruptionLeçon suivante →Rôles et privilèges