---
title: Ma haute disponibilité Postgres n'en était pas une, autopsie d'une panne
url: https://sxnlabs.com/opinion/2026/07/22/panne-postgres-ha-illusoire-scaleway/
lang: fr
date: '2026-07-22T18:00:00+02:00'
tags:
- PostgreSQL
- Scaleway
- Haute disponibilité
- Infrastructure
- Postmortem
---

# Ma haute disponibilité Postgres n'en était pas une, autopsie d'une panne

Hier soir, l'ensemble de mes services internes et les logiciels que j'héberge pour mes clients sont devenus injoignables pendant plusieurs heures. Une base Postgres saturée, une haute disponibilité qui n'a pas joué son rôle, et un incident Scaleway par-dessus. Voici l'autopsie, sans filtre, parce qu'une panne qu'on raconte honnêtement vaut mieux qu'une panne que l'on maquille.

## Le déclencheur, ou plutôt les déclencheurs

À 22h15 (heure de Paris), Scaleway perd un nœud de son cluster de block storage en fr-par-1 (incident `bsp2y5fysy9w`). Côté infra, le résultat est immédiat : des machines virtuelles bloquées, et surtout des bases managées gelées sur un stockage devenu inaccessible.

Au même moment, de mon côté, j'avais lancé un batch de jobs d'enrichissement de contacts sur Argos, mon CRM. Ce genre de batch ouvre beaucoup de connexions Postgres, et vite. Est-ce lui qui a saturé le pool, ou la base souffrait-elle déjà du storage Scaleway ? Je n'ai pas de réponse nette, et c'est exactement le piège des incidents corrélés : deux causes plausibles qui tombent dans la même fenêtre, et un doute qui ne se lève qu'après coup. Ce que je sais, c'est que les deux se sont nourris l'un l'autre. Une base qui répond mal, des connexions qui s'accumulent au lieu de se libérer, un batch qui continue d'en réclamer. Le pool atteint sa limite de connexions, et à partir de là, plus aucune application ne peut en ouvrir une seule. Tout tombe en cascade.

## Le vrai problème : une HA qui n'en était pas une

Ma base tournait en haute disponibilité, deux nœuds. Rassurant sur le papier. Sauf que les deux nœuds vivaient dans le même datacenter, fr-par-1. Quand l'étage block storage de fr-par-1 est tombé, mes deux répliques sont parties ensemble, à la même seconde. C'est la leçon que je retiens le plus : une redondance ne protège que contre ce qu'elle isole. La mienne couvrait la panne d'un process ou d'une machine, pas celle d'une zone entière. J'avais souscrit une assurance contre un risque, pas contre tous.

Pire, impossible de redémarrer la base. Le moteur Postgres managé restait accroché au stockage défaillant. Je pouvais tuer les connexions zombies et relancer mes applications autant que je voulais, le rétablissement final ne dépendait plus de moi : il était suspendu à la réparation de Scaleway. Se retrouver spectateur de sa propre panne, sans aucun levier, c'est le moment le plus désagréable de la soirée.

## La sortie de crise

La situation s'est débloquée dans la nuit, en combinant trois choses. J'ai coupé les connexions restées ouvertes côté Postgres, j'ai redémarré les applications pour repartir sur des pools propres, et Scaleway a fini par réparer le nœud de storage. Ce dernier point était le facteur décisif : sans lui, le reste ne servait à rien. Mes deux premières actions n'ont fait que préparer le terrain pour que tout reparte proprement une fois l'infra revenue.

## Ce que j'en tire, et ce que j'ai déjà fait

Un bon incident, c'est celui qui vous fait enfin faire ce que vous repoussiez. J'ai attaqué trois chantiers dans la foulée.

PgBouncer devant Postgres, d'abord. Un pooler de connexions que je voulais poser depuis longtemps sans jamais m'y mettre. Il borne le nombre de connexions et empêche un batch d'affamer toutes les autres applications. C'est en place.

Un failover en lecture seule dans une autre zone, ensuite. Mes deux nœuds de HA dans le même datacenter, c'était le cœur du problème. J'ai ajouté une réplique lecture seule ailleurs, pour qu'une zone Scaleway qui tombe ne m'emporte plus tout d'un bloc.

De l'observabilité sur les connexions, enfin. Surveiller `pg_stat_activity` et le taux de remplissage du pool, pour voir la saturation grimper et déclencher une alerte avant qu'elle ne tue tout, au lieu de la découvrir quand le service est déjà par terre.

## La leçon, en une phrase

Une dépendance d'infrastructure, aussi solide soit-elle sur le papier, reste un point de défaillance unique tant qu'on ne l'a pas explicitement isolée. Et une redondance qu'on n'a jamais testée contre le bon mode de panne n'est qu'une redondance de façade.

Si vous avez une infra dont vous répétez qu'elle est « en haute dispo » sans avoir vérifié contre quel type de panne exactement, on peut regarder ça ensemble, plutôt que de le découvrir un mardi soir.