Haute disponibilité MariaDB
Galera Cluster vs réplication asynchrone et semi-synchrone : quelle haute disponibilité pour MariaDB ?
Les trois répondent à des questions différentes : combien de données pouvez-vous perdre si le primaire tombe, quelle latence d'écriture acceptez-vous, et quelles contraintes votre application peut-elle supporter. Voici comment choisir, sans dogme.
La vraie question : que se passe-t-il au moment du commit ?
Tout se joue à un instant précis : quand l'application reçoit « OK » après un COMMIT, où la transaction existe-t-elle ? Sur le primaire seul, sur au moins un autre serveur, ou sur tout le cluster ? La réponse fixe votre perte de données possible en cas de panne, et le prix payé en latence à chaque écriture.
Aucun des trois modèles n'est « meilleur » dans l'absolu. Une réplication asynchrone bien supervisée, avec une bascule automatique, convient à la grande majorité des applications. Galera se justifie quand la perte d'une transaction validée n'est pas acceptable et que l'application respecte ses contraintes.
Réplication asynchrone : simple, rapide, avec une fenêtre de perte
Le primaire écrit la transaction dans son binlog et rend la main à l'application. Les réplicas récupèrent les événements ensuite, à leur rythme. Aucune attente d'un réplica au moment du commit, aucune contrainte de distance : un réplica peut être dans un autre pays pour le plan de reprise.
La contrepartie : si le primaire tombe, les transactions validées mais pas encore envoyées sont perdues ou restent bloquées sur le serveur en panne. Le retard des réplicas (lag) est aussi à surveiller : sous forte charge d'écriture ou pendant un gros ALTER TABLE, il peut atteindre plusieurs minutes. La réplication parallèle de MariaDB peut le réduire fortement, sans le garantir nul.
La bascule n'est pas automatique : il faut un outil qui détecte la panne, choisit le réplica le plus à jour, le promeut et rebranche les autres. C'est le rôle de Signal18 Replication Manager, avec un GTID qui simplifie le repositionnement des réplicas.
Réplication semi-synchrone : réduire la fenêtre de perte
En semi-synchrone, le primaire attend qu'au moins un réplica accuse réception de la transaction avant de confirmer le commit. Depuis MariaDB 10.3, c'est intégré au serveur, sans plugin à installer : on active rpl_semi_sync_master_enabled sur le primaire et rpl_semi_sync_slave_enabled sur les réplicas.
Deux réglages font toute la différence. Le wait point : avec AFTER_SYNC, le primaire attend l'accusé de réception avant de rendre la transaction visible, ce qui évite qu'un client lise une donnée qui disparaîtra après une bascule. La valeur par défaut de MariaDB est AFTER_COMMIT : vérifiez la vôtre. Le timeout : si aucun réplica ne répond dans le délai (rpl_semi_sync_master_timeout, 10 secondes par défaut), le primaire repasse en asynchrone sans faire échouer les commits. Seul le journal d'erreurs le signale, et le semi-synchrone reprend de lui-même quand un réplica a rattrapé son retard. Sans supervision de Rpl_semi_sync_master_status, vous pouvez tourner en asynchrone sans le savoir.
Deux limites à garder en tête. « Reçu » ne veut pas dire « appliqué » : un réplica peut avoir la transaction dans son relay log sans l'avoir encore exécutée, les lectures y restent donc en retard. Et chaque commit attend l'accusé de réception du premier réplica qui répond : réseau plus écriture de son relay log. Replication Manager peut conditionner la bascule automatique à l'état synchrone de la réplication (failover-at-sync), ce qui évite de promouvoir un réplica dont on sait qu'il est incomplet.
Galera Cluster : réplication synchrone par certification
Avec Galera, intégré à MariaDB, chaque transaction est diffusée à tous les nœuds au moment du commit, dans le même ordre partout, puis certifiée : chaque nœud vérifie qu'elle n'entre pas en conflit avec une transaction concurrente. Une transaction validée est connue de tous les nœuds du composant primaire. Il n'y a pas de réplica à promouvoir : si un nœud tombe, les autres continuent. Un nœud peut en revanche avoir un léger retard d'application, borné par le flow control.
Le quorum protège du split-brain : un nœud isolé du reste du cluster passe en état non primaire et refuse les requêtes. Un cluster de deux nœuds fonctionne, mais ne survit pas à la panne imprévue de l'un d'eux. D'où la règle des trois membres votants (trois nœuds de données, ou deux nœuds et un arbitre garbd), idéalement dans trois sites distincts.
Les contraintes sont réelles. Chaque commit paie au moins un aller-retour réseau vers les autres nœuds : on privilégie des sites proches, typiquement dans la même agglomération. Un déploiement sur WAN reste possible, mais la latence longue distance s'ajoute alors à chaque écriture. Le nœud le plus lent freine tout le cluster (flow control). En production, on utilise InnoDB et une clé primaire explicite sur chaque table (MyISAM et Aria ne sont supportés qu'à titre expérimental). La taille d'une transaction est limitée ; depuis Galera 4 (MariaDB 10.4), la streaming replication fragmente les très grosses transactions, avec un surcoût. Un ALTER TABLE bloque par défaut les écritures de tout le cluster pendant son exécution (mode TOI).
Écrire sur plusieurs nœuds en même temps est possible, mais quand deux transactions touchent les mêmes lignes sur deux nœuds différents, l'une des deux est annulée et l'application reçoit une erreur de deadlock (seuls certains autocommits sont rejoués automatiquement, via wsrep_retry_autocommit). En pratique, on route les écritures vers un seul nœud via un proxy (ProxySQL, MaxScale ou HAProxy), et on garde les autres pour la lecture et la reprise.
Comparatif côte à côte
Les trois modèles, critère par critère. Aucun ne gagne sur toutes les lignes.
| Critère | Asynchrone | Semi-synchrone | Galera Cluster |
|---|---|---|---|
| Quand le commit rend la main | Dès l'écriture locale | Quand au moins un réplica a reçu l'événement | Quand le write set est certifié par le cluster |
| Perte de données si le primaire tombe | Possible (événements pas encore envoyés) | Limitée, si wait point AFTER_SYNC et sans timeout | Aucune pour les transactions validées, tant que le quorum survit (si tout le cluster tombe d'un coup, cela dépend des réglages de flush) |
| Latence d'écriture ajoutée | Aucune attente d'un réplica au commit | Attente du premier accusé de réception d'un réplica (réseau + écriture du relay log) | Au moins un aller-retour vers les autres nœuds, à chaque commit |
| Lectures sur les secondaires | Possibles, avec retard | Possibles, avec retard (reçu ≠ appliqué) | Possibles ; lectures causales avec wsrep_sync_wait |
| Écritures sur plusieurs nœuds | Un seul écrivain dans la topologie standard (les anneaux multi-primaires existent, sans détection des conflits) | Un seul écrivain dans la topologie standard | Possibles, mais conflits sur les lignes chaudes : un seul écrivain recommandé |
| Nombre minimal de nœuds | 2 | 2 | 3 membres votants pour survivre à une panne (3 nœuds de données, ou 2 + garbd) |
| Bascule | Outil externe (ex. Replication Manager) | Outil externe (ex. Replication Manager) | Pas de promotion : le proxy cesse d'envoyer du trafic au nœud perdu |
| Distance entre sites | Quelconque, même intercontinentale | Sensible à la latence, même région de préférence | Faible latence de préférence (même agglomération) ; WAN possible, mais chaque commit paie la distance |
| Contraintes de schéma | Peu | Peu | InnoDB (MyISAM/Aria expérimentaux), clé primaire explicite sur chaque table fortement recommandée |
| Grosses transactions / DDL | Retard du réplica | Retard du réplica | Taille des write sets limitée (streaming replication pour les gros) ; un DDL bloque les écritures de tout le cluster par défaut (TOI) |
Quel modèle pour quelle situation ?
Application web classique, quelques secondes de perte acceptables en cas de panne rare
Asynchrone + bascule automatique (Replication Manager). Le plus simple à exploiter.
Perte de données à réduire, sans toucher à l'application
Semi-synchrone en AFTER_SYNC, avec supervision du repli en asynchrone.
Aucune transaction validée ne doit être perdue, sites proches
Galera 3 nœuds sur 3 sites, un seul écrivain via un proxy.
Réplica de secours dans une autre région ou un autre pays
Asynchrone. Sur cette distance, la latence ajoutée à chaque commit synchrone est rarement acceptable.
Tables sans clé primaire, MyISAM, très grosses transactions batch
Réplication classique, ou corriger le schéma avant d'envisager Galera.
Besoin de faire monter la lecture en charge
Les trois conviennent ; tenez compte du retard sur les réplicas asynchrones.
Et côté MySQL ?
La réplication asynchrone et semi-synchrone existe aussi sur MySQL, avec des noms de variables différents selon les versions. Galera existe pour MySQL via Percona XtraDB Cluster. La solution native d'Oracle, Group Replication / InnoDB Cluster, repose sur un autre protocole. Nous ne la prenons pas en charge : sur MySQL, notre périmètre couvre le standalone et la réplication classique.
Ce que nous exploitons chez RDEM Systems
Nos deux topologies de MariaDB as a Service recouvrent ce comparatif : réplication sur 2 datacenters pilotée par Replication Manager, et Galera Cluster sur 3 datacenters en Île-de-France, assez proches pour que la latence de certification reste faible.
Notre propre infrastructure PKI tourne sur Galera : architecture, quorum et supervision sont détaillés dans l'étude de cas du cluster Galera 3 nœuds. Si vous hésitez entre les modèles, l'audit MariaDB vérifie d'abord si votre schéma et vos transactions sont compatibles avec Galera.
Questions fréquentes
Galera est-il vraiment synchrone ?
La diffusion et la certification sont synchrones : une transaction validée est connue de tous les nœuds du composant primaire. L'application sur chaque nœud reste légèrement différée, d'où le terme « virtuellement synchrone ». Pour garantir qu'une lecture voit les dernières écritures, on utilise wsrep_sync_wait.
La réplication semi-synchrone garantit-elle zéro perte de données ?
Non. Elle limite fortement la fenêtre de perte avec le wait point AFTER_SYNC, mais repasse en asynchrone si aucun réplica ne répond avant le timeout. Ce repli est journalisé, mais tant qu'il n'est pas supervisé, la garantie reste théorique.
Peut-on faire un cluster Galera avec deux nœuds ?
Il fonctionne, mais si l'un tombe de façon imprévue, l'autre perd le quorum et refuse les requêtes. Pour tolérer une panne, il faut un troisième membre, qui peut être un arbitre garbd sans données.
Faut-il écrire sur tous les nœuds Galera ?
C'est possible, mais des écritures concurrentes sur les mêmes lignes font annuler l'une des transactions, que l'application doit rejouer. La pratique courante est un seul nœud écrivain, les autres servant à la lecture et à la reprise.
Votre haute disponibilité tient-elle vraiment en cas de panne ?
L'audit MariaDB passe en revue la topologie, la réplication, la bascule et la compatibilité de votre schéma avec Galera.
Démarrez votre projet MariaDB infogéré
Discutons de vos besoins en bases de données. Notre équipe DBA vous conseille sur l'architecture optimale pour votre cas d'usage.
RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise