L'équipe « ajoute de la réplication pour la performance ». Deux mois plus tard : master saturé, réplica inactif à 4 % de processeur, budget doublé. Autre scénario : basculement « automatique » activé — l'application écrit encore sur l'ancienne adresse IP du master tombe — vingt minutes d'indisponibilité.
La réplication résout un problème bien posé :
- Disponibilité (survivre à la mort du master)
- Montée en charge lecture (délestage des SELECT)
- Reporting (analytique sans tuer la production)
- Proximité géographique (lecture locale — avec cohérence faible)
Choisir « réplica parce que c'est professionnel » sans routage de lecture = coût plus complexité sans gain.
Matrice objectif → architecture
| Objectif | Modèle | Piège |
|---|---|---|
| Haute disponibilité | Primary + standby synchrone/semi-synchrone + Patroni | Split-brain non testé |
| Montée en charge lecture | Réplicas asynchrones + proxy lecture/écriture | Décalage UX post-écriture |
| Sauvegarde en direct | Réplica retardé | Ne remplace pas une sauvegarde testée |
| Lecture géographique | Réplica régional | Conflits de cohérence |
Un réplica n'est pas une sauvegarde — la corruption logique se réplique aussi.
Décalage de réplication et expérience utilisateur web
Après inscription :
// POST master → redirect GET /profile
// GET sur replica → utilisateur pas encore visible si décalage 2s
Solutions :
- Lecture de ses propres écritures : session collante sur le master N secondes post-écriture.
- Proxy : ProxySQL, PgBouncer avec routage intelligent.
- CQRS : accepter la cohérence éventuelle côté interface.
MySQL vs PostgreSQL : vue exploitation
MySQL : binlog asynchrone/semi-synchrone ; réplicas en lecture ; basculement MHA/Orchestrator.
PostgreSQL : réplication en flux ; hot standby en lecture ; basculement Patroni + etcd.
Base managée (RDS, Cloud SQL, OVH DB) : Multi-AZ ≠ réplica en lecture — lisez la documentation produit. Pour choisir l'hébergement, voir VPS ou cloud et l'annuaire.
Quand un réplica sur le même hébergeur suffit — ou non
| Charge | Recommandation |
|---|---|
| Blog, petit SaaS | Instance unique plus sauvegardes testées |
| Lecture >> écriture mesurée | Un ou deux réplicas en lecture |
| SLA 99,9 %+ | Haute disponibilité managée ou équipe Patroni |
| Analytique lourde | Réplica dédié au reporting |
Un réplica sur le même serveur physique (certains mutualisés ou offres entrée de gamme) est une illusion de haute disponibilité : panne matérielle, panne des deux. Avant d'ajouter un réplica, mesurez le ratio lecture/écriture avec pg_stat_statements ou votre outil de supervision applicative — un master mal indexé restera lent même avec trois réplicas inutilisés.
Le sommet : répliquer double les données — pas la disponibilité sans tests
Voici ce que le slide « haute disponibilité » oublie de montrer.
Budget : exercice de basculement trimestriel > troisième réplica inutilisé.
Décider et avancer sans angle mort
Avant d'ajouter un réplica, formulez l'objectif en une phrase :
- Formulez l'objectif : haute disponibilité, lecture, reporting ou géographie.
- Mesurez le ratio lecture/écriture de vos routes applicatives.
- Routez explicitement les SELECT si montée en charge lecture.
- Surveillez le décalage plus alertes au-delà du seuil métier.
- Testez la basculement documenté au moins une fois par trimestre.
Un réplica sans routage de lecture ni exercice de basculement est une ligne de budget, pas une assurance. Croisez avec EXPLAIN PostgreSQL pour optimiser le master avant de le dupliquer.
Questions fréquentes
Un réplica en lecture accélère-t-il automatiquement mon site ?
Seulement si vous routez explicitement les SELECT vers le réplica et que la charge est majoritairement en lecture. Si tout passe par le master, le réplica reste inactif et inutile pour la performance.
Qu'est-ce que le décalage de réplication ?
C'est le délai entre le commit sur le master et la visibilité sur le réplica. Un décalage de quelques secondes peut faire disparaître temporairement les données qu'un utilisateur vient d'écrire.
Réplication synchrone vs asynchrone ?
La synchrone limite la perte de données mais augmente la latence d'écriture. L'asynchrone améliore les performances d'écriture au prix d'un risque de perte si le master meurt avant propagation.
La bascule automatique est-elle prête à l'emploi ?
Non. Elle nécessite un orchestrateur, des tests réguliers et une gestion du split-brain. DNS ou adresse virtuelle doivent basculer vers le nouveau master — rien n'est automatique sans configuration et exercice.
Répliquer sans objectif, c'est payer deux fois pour la même requête mal indexée sur le master.