Haute disponibilité : Always On, Data Guard ou Patroni ?

Le principe commun

Un serveur principal reçoit les écritures. Un ou plusieurs serveurs secondaires en reçoivent une copie en continu. En cas de panne, un secondaire devient principal, automatiquement ou sur décision humaine. Deux choix structurent tout le reste :

• synchrone ou asynchrone : le mode synchrone n'accepte une transaction qu'une fois confirmée sur le secondaire, donc sans perte de données, mais avec une latence supplémentaire ; le mode asynchrone est plus rapide, mais une panne peut faire perdre les dernières transactions ;
• automatique ou manuel : le basculement automatique réduit l'arrêt, mais exige un mécanisme de décision fiable pour éviter le « split-brain », deux serveurs se croyant principal en même temps.

La haute disponibilité ne remplace pas la sauvegarde : elle réplique aussi les erreurs, comme une suppression par erreur.

SQL Server : les groupes de disponibilité Always On

Un groupe de disponibilité regroupe plusieurs bases qui basculent ensemble, entre un réplica principal et des réplicas secondaires, en mode synchrone ou asynchrone. Le basculement automatique est possible avec un réplica synchrone. Les secondaires peuvent servir à la lecture ou aux sauvegardes. La solution s'appuie sur un cluster (Windows Server Failover Clustering, ou Pacemaker sous Linux). L'édition Standard est limitée à des groupes de disponibilité de base : l'édition Enterprise est nécessaire pour l'ensemble des fonctions. Les instances de cluster de basculement, avec stockage partagé, restent une alternative.

Oracle : Data Guard

Data Guard maintient une ou plusieurs bases de secours à partir du journal de la base principale. Trois modes de protection existent, du plus strict (aucune perte de données) au plus performant. Le basculement automatique (Fast-Start Failover) s'appuie sur un observateur. Active Data Guard, une option distincte, permet de lire sur la base de secours pendant la réplication. Il faut prendre en compte la licence : Data Guard relève de l'édition Enterprise, et certaines options sont payantes. Ne pas confondre avec Oracle RAC, qui protège contre la panne d'un serveur au sein d'un même site, et non contre la perte du site.

PostgreSQL : la réplication native et Patroni

PostgreSQL sait répliquer en continu vers des secondaires, en synchrone ou en asynchrone. Mais il ne décide pas seul du basculement. Des outils s'en chargent : Patroni, qui s'appuie sur un magasin de consensus (etcd, Consul ou ZooKeeper) pour élire le serveur principal, ainsi que repmgr ou pg_auto_failover. Il faut ajouter une couche d'accès (HAProxy, adresse virtuelle ou répartiteur) pour que les applications retrouvent le principal après la bascule.

Les pièges à éviter

• ne jamais tester la bascule : elle échoue le jour de la panne ;
• des applications qui ne se reconnectent pas, faute de bonne chaîne de connexion ou de point d'accès unique ;
• des éléments non répliqués : comptes, tâches planifiées et paramètres de l'instance (par exemple sous SQL Server) ;
• un secondaire sous-dimensionné, qui ne tient pas la charge en cas de bascule ;
• un mode synchrone sur une liaison lente, qui dégrade les performances ;
• le split-brain, faute de témoin ou de quorum correctement configuré ;
• des licences mal anticipées pour les serveurs secondaires.

Comment choisir

On part du besoin, pas de l'outil : perte de données acceptable (RPO), durée d'arrêt acceptable (RTO), budget, compétences de l'équipe, et nombre de sites. Un secondaire local avec basculement automatique n'a pas le même coût qu'une solution multi-sites. Dans tous les cas, la bascule se teste à intervalles réguliers, et la procédure se documente.