Haute disponibilité MariaDB
ProxySQL vs MaxScale (et HAProxy) devant MariaDB et Galera : lequel choisir ?
Devant un cluster MariaDB, il faut une couche qui envoie chaque connexion vers le bon serveur, et qui arrête de l'envoyer vers un nœud tombé. ProxySQL et MaxScale comprennent le SQL, HAProxy ne voit que du TCP. Voici ce que chacun apporte, ce qu'il coûte en exploitation, et le changement de licence de MaxScale à connaître avant de choisir.
Proxy SQL ou répartiteur TCP : deux métiers différents
Un répartiteur TCP comme HAProxy transmet des octets. Il sait si un serveur répond à un health check, pas ce que contient la requête. On l'utilise avec un port pour les écritures et un autre pour les lectures, et c'est l'application qui choisit le bon port.
Un proxy SQL comme ProxySQL ou MaxScale lit le protocole MySQL. Il peut envoyer les SELECT vers les réplicas et le reste vers le primaire sur un seul port, mutualiser les connexions, bloquer ou réécrire certaines requêtes, et suivre l'état de la réplication ou de Galera pour retirer un nœud en retard. En contrepartie, il faut le configurer, le superviser et comprendre ses effets de bord.
Dans les deux cas, le proxy ne remplace pas la supervision de la topologie. En réplication asynchrone, quelqu'un doit promouvoir un nouveau primaire : MaxScale sait le faire, ProxySQL et HAProxy non. Signal18 Replication Manager pilote la bascule et met à jour ProxySQL, MaxScale ou HAProxy dans la foulée.
ProxySQL : le couteau suisse open source
ProxySQL est un proxy sous licence GPLv3 qui fonctionne avec MySQL comme avec MariaDB. Les serveurs sont rangés dans des hostgroups (écriture, lecture, secours) et des règles de requêtes décident où part chaque requête. Les mêmes règles servent à mettre en cache, réécrire, limiter ou bloquer des requêtes précises.
Pour Galera, la table mysql_galera_hostgroups gère nativement le modèle à un seul écrivain : ProxySQL surveille l'état wsrep de chaque nœud, garde max_writers écrivains actifs, bascule sur un écrivain de secours si le nœud tombe, et sort des lectures un nœud trop en retard.
Son point fort est le multiplexage : des milliers de connexions applicatives partagent quelques dizaines de connexions vers MariaDB. Les variables de session courantes que ProxySQL suit (jeu de caractères, sql_mode, fuseau horaire…) ne le gênent pas. En revanche, une transaction ouverte suspend le partage de la connexion jusqu'à sa fin, et certains états le désactivent jusqu'à la fermeture de la connexion : table temporaire, verrou, variable de session non suivie. C'est connexion par connexion, pas pour tout le pool, mais un ORM qui pose ce type d'état à chaque requête en perd l'essentiel du bénéfice.
La contrepartie, c'est une configuration par interface d'administration SQL, en trois couches (mémoire, runtime, disque) qu'il faut charger et sauvegarder explicitement. Une modification oubliée en mémoire, jamais passée au runtime ou jamais écrite sur disque, est un classique des incidents ProxySQL.
MaxScale : l'intégration MariaDB, avec une licence à vérifier
MaxScale est le proxy de MariaDB plc. Son routeur readwritesplit sépare lectures et écritures, et sait garantir qu'une lecture voit l'écriture précédente de la même session (causal_reads, qui demande MariaDB 10.2.16 ou plus ; avec Galera, seuls les modes fast* fonctionnent, depuis MaxScale 24.02.5) ou rejouer une transaction interrompue par une bascule (transaction_replay).
Il intègre ses propres moniteurs : galeramon pour Galera, et mariadbmon pour la réplication asynchrone, qui sait promouvoir un réplica automatiquement. C'est le seul des trois à gérer la bascule lui-même. Il reste pensé pour MariaDB : il parle le protocole MySQL, mais ses fonctions avancées visent MariaDB.
Le point à vérifier avant tout : la licence. Depuis la version 25.01 (janvier 2025), MaxScale est sous licence commerciale propriétaire : l'usage en production nécessite un abonnement MariaDB Enterprise. Les versions antérieures ont été publiées sous Business Source License (gratuites en production avec moins de trois serveurs), chacune convertie en GPL à une date propre. Au 28 septembre 2026, les branches 23.08 et antérieures sont passées en GPL (23.08 le 21 septembre 2026) ; 24.02 et 24.08 restent sous BSL jusqu'en 2027. Sans abonnement et au-delà de deux serveurs, il ne reste donc que des branches GPL qui ne recevront plus de nouvelles fonctions.
HAProxy : simple, robuste, sans connaissance du SQL
HAProxy fait une seule chose : envoyer une connexion TCP vers un serveur en bonne santé. Devant Galera, on l'associe à un script de health check HTTP (le classique clustercheck) qui répond « OK » seulement si le nœud est synchronisé. Un serveur actif pour les écritures, les autres en backup : on obtient le modèle à un seul écrivain pour les nouvelles connexions, sans proxy SQL. Attention au retour du serveur principal : les sessions déjà ouvertes sur un secours y restent, sauf si l'on ajoute on-marked-up shutdown-backup-sessions.
Pas de séparation lecture / écriture automatique, pas de pool, pas de règles. Mais une configuration de vingt lignes, une empreinte mémoire minime et un comportement très prévisible. C'est souvent le bon choix quand l'application sait déjà utiliser deux ports ou quand la charge ne justifie pas un proxy SQL.
Comparatif côte à côte
Aucun ne gagne sur toutes les lignes : le choix dépend de ce dont l'application a besoin.
| Critère | ProxySQL | MaxScale | HAProxy |
|---|---|---|---|
| Couche | Protocole SQL (L7) | Protocole SQL (L7) | TCP (L4) |
| Licence | GPLv3, gratuit | 25.01+ : propriétaire, abonnement Enterprise en production. 24.02 / 24.08 : BSL jusqu'en 2027. 23.08 et antérieures : désormais GPL | GPLv2, gratuit |
| Séparation lecture / écriture | Oui, via règles de requêtes et hostgroups | Oui, routeur readwritesplit | Non (un port par rôle) |
| Pool de connexions | Oui, avec multiplexage | Réutilisation des connexions, plus limitée | Non |
| Règles, réécriture, cache | Oui, très fin | Oui, via des filtres | Non |
| Connaissance de Galera | mysql_galera_hostgroups (un écrivain, écrivains de secours) | Moniteur galeramon | Via un health check HTTP (clustercheck) |
| Bascule en réplication asynchrone | Suit la topologie ; la promotion est faite par un outil externe | Intégrée (mariadbmon) | Non ; outil externe |
| Support MySQL | MySQL et MariaDB | Conçu pour MariaDB ; fonctions avancées réservées à MariaDB | Tous (indépendant du protocole) |
| Configuration | Interface d'admin SQL, couches memory / runtime / disk | Fichier, API REST, maxctrl, interface web | Fichier de configuration |
| Complexité d'exploitation | Moyenne à élevée | Moyenne | Faible |
Configurations minimales devant un Galera 3 nœuds
Exemples à adapter (adresses, utilisateurs de supervision, mots de passe). Ils illustrent le modèle à un seul écrivain, pas une configuration de production complète.
ProxySQL : hostgroups Galera, un écrivain actif
-- Interface d'admin ProxySQL (port 6032)
-- Prérequis : un utilisateur de supervision (mysql-monitor_username)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES
(10, 'db1', 3306), (10, 'db2', 3306), (10, 'db3', 3306);
INSERT INTO mysql_galera_hostgroups
(writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
offline_hostgroup, active, max_writers, writer_is_also_reader,
max_transactions_behind)
VALUES (10, 12, 11, 13, 1, 1, 2, 100);
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;MaxScale : moniteur Galera et séparation lecture / écriture
# /etc/maxscale.cnf (sections [db1] [db2] [db3] non montrées)
[Galera-Monitor]
type=monitor
module=galeramon
servers=db1,db2,db3
user=maxscale_monitor
password=...
monitor_interval=2s
[RW-Split]
type=service
router=readwritesplit
cluster=Galera-Monitor
user=maxscale
password=...
[RW-Listener]
type=listener
service=RW-Split
port=3306HAProxy : un écrivain, deux secours, health check clustercheck
# haproxy.cfg — clustercheck répond en HTTP sur le port 9200
listen galera-write
bind *:3306
mode tcp
option httpchk
default-server port 9200 inter 2s fall 3 rise 2
server db1 10.0.0.1:3306 check
server db2 10.0.0.2:3306 check backup
server db3 10.0.0.3:3306 check backupLequel pour quelle situation ?
Galera en écrivain unique, application qui gère déjà ses connexions
HAProxy + clustercheck. Le plus simple à exploiter.
Beaucoup de connexions courtes (PHP, serverless), lectures à répartir
ProxySQL : multiplexage et séparation lecture / écriture.
Besoin de bloquer, réécrire ou mettre en cache des requêtes sans toucher au code
ProxySQL et ses règles de requêtes.
Environnement MariaDB avec abonnement Enterprise
MaxScale : intégration la plus poussée, bascule et lectures causales intégrées.
Réplication asynchrone avec bascule automatique, sans abonnement
Replication Manager pour la bascule, ProxySQL ou HAProxy devant.
Parc mixte MySQL et MariaDB
ProxySQL ou HAProxy, qui traitent les deux de la même façon.
Pièges fréquents
- Le proxy devient le point unique de panne. Déployez-en deux avec une IP virtuelle (keepalived), ou un proxy local sur chaque serveur applicatif.
- Séparer lectures et écritures sans penser au retard des réplicas : un utilisateur enregistre, recharge la page et ne voit pas sa modification. Limitez le retard accepté ou gardez les lectures critiques sur le primaire.
- Écrire sur plusieurs nœuds Galera « parce que le proxy le permet » : les conflits de certification reviennent à l'application sous forme de deadlocks. Voir Galera vs réplication.
- Compter sur le multiplexage de ProxySQL alors que l'application pose des variables de session ou des tables temporaires à chaque requête : le multiplexage est désactivé sur ces connexions et le pool n'apporte presque plus rien.
- Mettre à jour MaxScale vers une version 25.x sans vérifier la licence : en production, sans abonnement, ce n'est pas couvert.
Notre approche chez RDEM Systems
Nous n'avons pas de proxy imposé. Sur les topologies en réplication, Replication Manager pilote la bascule et met à jour le proxy en place, qu'il s'agisse de ProxySQL, HAProxy ou MaxScale. Devant Galera, un proxy qui route les écritures vers un seul nœud est le choix le plus courant. Un proxy SQL n'est pas obligatoire pour autant : sur notre propre cluster Galera 3 nœuds, les serveurs applicatifs se connectent directement aux nœuds, avec une répartition de charge en couche 4 (IPVS).
Si vous avez déjà un proxy en place, l'audit MariaDB vérifie sa configuration, sa redondance et son comportement pendant une bascule. Pour les autres outils du quotidien, voir notre boîte à outils DBA MariaDB / MySQL.
Questions fréquentes
MaxScale est-il encore gratuit ?
Depuis la version 25.01 (janvier 2025), MaxScale est sous licence commerciale propriétaire et son usage en production nécessite un abonnement MariaDB Enterprise. Les versions antérieures étaient sous Business Source License (gratuites en production avec moins de trois serveurs) et passent en GPL à une date propre à chaque version : au 28 septembre 2026, les branches 23.08 et antérieures sont en GPL, 24.02 et 24.08 restent sous BSL jusqu'en 2027.
ProxySQL fonctionne-t-il avec MariaDB et Galera ?
Oui. ProxySQL est compatible MariaDB et gère Galera nativement via la table mysql_galera_hostgroups : un ou plusieurs écrivains actifs, des écrivains de secours, et l'exclusion automatique des nœuds indisponibles ou désynchronisés (un nœud donneur de SST peut rester en service si wsrep_sst_donor_rejects_queries est désactivé).
HAProxy suffit-il devant un cluster Galera ?
Souvent, oui. Avec un health check qui vérifie l'état de synchronisation du nœud et un seul serveur actif pour les écritures, HAProxy fournit le modèle à un seul écrivain. Il ne sépare pas les lectures des écritures : l'application doit viser deux points d'accès distincts (typiquement deux ports) si elle veut répartir ses lectures.
Le proxy gère-t-il la bascule du primaire ?
Seul MaxScale sait promouvoir un réplica en réplication asynchrone. ProxySQL et HAProxy suivent la topologie mais ne promeuvent rien : il faut un outil comme Replication Manager pour décider de la bascule et mettre à jour le proxy.
Votre proxy tient-il pendant une bascule ?
L'audit MariaDB teste la topologie, le proxy et la bascule, et vérifie qu'aucun composant ne reste point unique de panne.
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