HA de la base de données.
La couche la plus délicate : c'est elle qui porte l'état. On ne peut pas simplement « ajouter un serveur » — il faut répliquer les données, gérer la bascule et éviter la corruption. C'est presque toujours le vrai point de panne unique d'une application.
Sauvegarde ≠ haute disponibilité
Une sauvegarde vous permet de restaurer les données après un incident — mais la restauration prend du temps (minutes à heures), pendant lequel le service est à l'arrêt. La HA vise le contraire : quand la base primaire tombe, une autre prend le relais immédiatement, sans restauration. Les deux sont indispensables et ne se remplacent pas.
1. Réplication primaire → replica
Le modèle le plus courant. Une base primaire accepte les écritures et diffuse ses modifications à un ou plusieurs replicas. En cas de panne de la primaire, un replica est promu (failover). Un outil de bascule (Patroni, orchestrator) automatise la promotion et redirige les applications.
Synchrone vs asynchrone : en réplication asynchrone, la primaire confirme l'écriture sans attendre le replica (rapide, mais RPO > 0 : on peut perdre les dernières transactions). En synchrone, elle attend l'accusé du replica (RPO = 0, mais latence accrue). Le choix dépend de la tolérance à la perte de données.
2. Cluster multi-maître (Galera)
Avec Galera (MariaDB/MySQL), tous les nœuds acceptent lectures et écritures, et se synchronisent de façon synchrone. Pas de promotion à gérer : si un nœud tombe, les autres continuent. On préconise un nombre impair de nœuds (3, 5) pour le quorum et éviter le split-brain.
Notions clés
Read/write split (ProxySQL)
Un proxy SQL (ProxySQL, MaxScale) place devant le cluster : il envoie les écritures vers la primaire et distribue les lectures sur les replicas. L'application se connecte à une seule adresse et ignore la topologie — pratique pour absorber une charge de lecture massive.
Failover automatique
Patroni (PostgreSQL) ou orchestrator (MySQL/MariaDB) détectent la panne de la primaire, élisent un replica à jour, le promeuvent et redirigent le trafic. Sans automatisation, la bascule manuelle peut prendre de longues minutes en pleine nuit.
Split-brain & quorum
Si le réseau coupe un cluster en deux, chaque moitié pourrait se croire seule maître et accepter des écritures divergentes — corruption. Le quorum (majorité stricte) impose qu'une seule partition, celle qui détient la majorité, reste active. D'où le nombre impair de nœuds.
Lag de réplication
Un replica asynchrone peut être en retard de quelques secondes. Lire immédiatement après une écriture sur un replica peut renvoyer une donnée périmée. On gère ça côté application (lecture forcée sur la primaire pour les données fraîches) ou via un proxy conscient du lag.
Sécuriser votre base de données
Réplication, cluster ou failover automatique : on choisit l'architecture adaptée à votre RPO/RTO et à votre volume.
Demander un devisExplorer le pôle infogérance & haute disponibilité
Infogérance de serveur
Supervision, mises à jour, sauvegardes testées, durcissement et réponse à incident.
Exploitation & supervisionReprise d’infogérance
Vous changez d’infogéreur ? On reprend l’existant, même sans documentation ni accès complets.
Depuis un autre prestataireHaute disponibilité
SPOF, redondance, failover, RTO/RPO : supprimer les points de panne uniques.
Concepts & architectureHA des frontaux web
Répartition de charge, health checks, VIP flottante, frontaux stateless.
Load balancing & failoverHA du stockage
Stockage partagé/répliqué, objet S3, sauvegardes 3-2-1, redondance géo.
Fichiers & données répliqués