Décision : quelle solution HA/DR ?
Le choix d'une solution de haute disponibilité et de reprise après sinistre ne commence pas par la technologie mais par l'équilibre entre les exigences métier (RTO/RPO), le besoin de répartition géographique et le coût. En partant de votre tolérance à l'interruption et à la perte de données, cet arbre vous oriente vers la bonne approche parmi réplicas synchrones, standbys asynchrones, clusters à failover automatique et sauvegarde+PITR.
Quelle est votre tolérance à la perte de données (RPO) ?
Commencez par la contrainte la plus forte : en cas de sinistre, combien de secondes de données pouvez-vous vous permettre de perdre ? Si une perte de données nulle (RPO=0) est exigée, la réplication synchrone est obligatoire ; si quelques secondes/minutes sont acceptables, des solutions asynchrones et des approches moins coûteuses deviennent possibles. L'objectif de RPO conditionne généralement toutes les autres décisions.
- Perte de données nulle obligatoire (RPO = 0)
- Quelques secondes/minutes de perte de données sont acceptables
Une reprise automatique et rapide (RTO faible) est-elle aussi requise ?
Vous voulez une perte de données nulle ; mais en combien de temps devez-vous être de nouveau opérationnel quand le primaire tombe ? Failover automatique en quelques secondes, ou une courte fenêtre d'intervention manuelle est-elle acceptable ? Cela fait la différence entre un simple réplica synchrone et un cluster entièrement automatisé.
- Failover automatique en quelques secondes requis
- Une reprise manuelle/planifiée suffit ; la perte nulle prime
Une autre région/zone géographique est-elle requise (DR) ?
Si une certaine perte de données est acceptable, la vraie question est le périmètre de résilience : devez-vous être protégé contre la perte d'un data center/d'une région entière, ou une protection contre la panne d'un seul nœud dans la même région suffit-elle ? Si la répartition géographique est requise, un standby asynchrone s'impose ; sinon, on évalue les options privilégiant le coût.
- Oui, une région distincte contre les sinistres géographiques est obligatoire
- Non, budget et simplicité priment
Pouvez-vous accepter un temps de reprise long (RTO élevé) ?
Vous restez dans une seule région et tolérez une certaine perte de données. Visez-vous le coût le plus bas, ou voulez-vous un nœud standby qui reprend rapidement en cas de panne ? Si une reprise de plusieurs heures est acceptable, sauvegarde+PITR seul est la voie la plus économique ; sinon, il vous faut un warm standby.
- Oui, une reprise de plusieurs heures est acceptable (le moins cher)
- Non, un warm standby qui reprend en quelques minutes est requis
Recommandation : réplica synchrone (perte de données nulle)
Le primaire ne termine pas un commit tant qu'au moins un standby ne l'a pas acquitté ; ainsi, même si le primaire est perdu, aucune transaction acquittée n'est perdue (RPO=0). La solution idéale au sein d'une région sur un réseau à faible latence.
Recommandation : standby asynchrone (DR géographique)
Le standby applique les modifications en flux sans retarder les commits du primaire. C'est la méthode standard pour conserver une copie dans une autre région sans nuire aux performances en écriture ; en contrepartie, une petite fenêtre de perte de données (égale au retard de réplication) est acceptée.
Recommandation : cluster à failover automatique
Une solution de cluster combinant supervision de santé, élection de leader et reprise automatique ; elle vise à la fois un RTO faible (failover automatique en quelques secondes) et un RPO faible/nul avec une copie synchrone. La charge opérationnelle est plus élevée, mais l'intervention humaine est réduite au minimum.
Recommandation : sauvegarde + PITR (le plus économique)
Au lieu d'un standby en fonctionnement, seuls des sauvegardes régulières et la restauration à un instant donné (PITR) via les WAL/journaux archivés sont conservés. C'est la solution la moins coûteuse ; le prix à payer est une reprise qui peut prendre des heures (RTO élevé).