Aller au contenu

Bases de données Mis à jour le 2026-05-29

MySQL / MariaDB / Percona haute disponibilité

Topologies haute disponibilité pour MySQL, MariaDB et Percona sur Stack Harbor PaaS — auto-clustering, primaire-secondaire, multi-primaire, Galera et grappes multi-régions.

Stack Harbor PaaS provisionne les grappes MySQL, MariaDB et Percona depuis l’assistant de topologie. Cette page couvre les topologies HA disponibles, quand choisir chacune, et ce que la plateforme prend en charge par rapport à ce que vous configurez.

Ce que fait l’auto-clustering

Quand vous activez Auto-Clustering à la création, la plateforme :

  • Provisionne le nombre choisi de nœuds base de données.
  • Configure la réplication entre eux selon le schéma sélectionné.
  • Met en place un palier ProxySQL en frontal de la grappe, avec les règles de routage SQL câblées.
  • Émet un point de terminaison applicatif unique — proxy.{environment_name}.{domain} — qui survit aux basculements de nœud.
  • Câble les crochets d’auto-restauration (voir plus bas).

Les applications visent le point ProxySQL, pas les nœuds individuels, donc un basculement de nœud n’exige pas de redémarrer l’application.

Topologies disponibles

Auto-clustering

Choisir le schéma dans l’assistant de topologie. Les schémas disponibles sont :

  • Primary-Secondary
  • Primary-Primary
  • Galera (MariaDB uniquement)

La même boîte de dialogue fixe aussi le nombre de nœuds, la limite de cloudlets par nœud, et le dimensionnement ProxySQL.

Réplication Primary-Secondary

Réplication asynchrone. Un écrivain (primaire), un ou plusieurs lecteurs (secondaires). La primaire diffuse un journal binaire ; les secondaires lisent et appliquent. Idéal pour des charges dominées par les lectures où la grappe doit servir plus de trafic de lecture qu’un nœud unique ne peut.

Voir Réplication primaire-secondaire pour la procédure d’installation manuelle.

Réplication Multi-Primary

Réplication asynchrone bidirectionnelle entre deux primaires. Les deux nœuds acceptent les écritures ; les conflits sont résolus selon des règles configurées. Idéal pour des écritures HA — si une primaire tombe, l’autre prend le relais, sans étape de promotion.

Note sur la résolution de conflit : multi-primaire n’est pas un substitut à une topologie écrivain-unique quand votre charge inclut des écritures concurrentes sur la même ligne depuis des primaires différentes. Galera est plus adapté là.

Grappe Galera

Réplication multi-primaire synchrone sur MariaDB. Tous les nœuds acceptent les écritures ; les transactions ne sont validées qu’à l’atteinte d’un quorum de write-set. Idéal pour des écritures HA avec cohérence forte.

Galera a quelques particularités opérationnelles — récupération split-brain, gestion de l’état joiner, le réglage wsrep_provider — documentées dans la référence Galera amont. L’installation auto-clustering de la plateforme livre des valeurs par défaut saines.

Grappe multi-régions

Une topologie en grappe répartie sur deux ou plusieurs régions d’environnement. Chaque région contient une partie de la grappe ; la réplication est asynchrone entre régions. Idéal pour des topologies de reprise après sinistre où vous devez survivre à la perte d’une région entière.

Note sur la latence : la performance en écriture dans une grappe multi-régions est bornée par la latence inter-régions. Pour des charges sensibles à la latence d’écriture, préférer une topologie HA mono-région et faire tourner une réplique séparée dans une autre région pour la DR.

Module Cluster Recovery

Le module Cluster Recovery surveille la santé de la grappe et redémarre les membres qui décrochent. Il gère les pannes transitoires courantes — un bref hoquet réseau, un événement OOM sur un nœud — automatiquement, sans intervention d’un opérateur.

Installez-le depuis le marketplace sur tout environnement MySQL en grappe. Le module est opt-in ; nous recommandons de l’installer sur tout environnement en production en grappe.

Récupération de grappe Galera

Quand une grappe Galera subit une panne totale — tous les nœuds tombés simultanément — la grappe doit être amorcée depuis le nœud au seqno le plus élevé. La procédure :

  1. Identifier le nœud au seqno le plus élevé (regarder grastate.dat sur chaque nœud).
  2. Amorcer ce nœud en premier avec galera_new_cluster (ou le script équivalent de votre version).
  3. Démarrer les nœuds restants — ils rejoindront comme récipiendaires de transfert d’état.

Le module Cluster Recovery automatise cela pour les pannes partielles. Les pannes totales demandent toujours une revue par un opérateur, parce qu’un mauvais choix de nœud d’amorçage perd des transactions validées.

Voir aussi