Un client opérant une plateforme de vente de billets en ligne sous WordPress et WooCommerce avait un besoin précis, formulé sans détour lors du cadrage : « la moindre coupure de base de données pendant une mise en vente nous coûte des ventes irrattrapables ». Une réplication classique maître-esclave asynchrone, avec bascule manuelle en cas de panne, ne suffisait plus : il fallait une architecture capable d’encaisser la perte d’un serveur sans interruption de service perceptible.
Percona XtraDB Cluster, distribution basée sur la technologie de réplication Galera, répond précisément à ce besoin : plusieurs nœuds MySQL/MariaDB répliqués en écriture synchrone, chacun capable de servir des écritures, avec un mécanisme de quorum qui empêche toute incohérence en cas de panne partielle.
Le principe de la réplication synchrone Galera
À la différence d’une réplication MySQL classique, où une transaction est validée sur le maître puis propagée aux esclaves avec un délai variable, Galera certifie une transaction sur l’ensemble des nœuds du cluster avant de la considérer comme validée. Concrètement, une écriture n’est confirmée au client que lorsque tous les nœuds actifs l’ont acceptée, ce qui élimine le risque de lecture d’une donnée obsolète sur un nœud différent de celui qui a reçu l’écriture.
Cette garantie a un coût : la latence d’écriture augmente légèrement (le temps de certification réseau entre nœuds), et un nœud dont la connexion réseau se dégrade peut ralentir l’ensemble du cluster, puisque chaque écriture attend la confirmation de tous les membres actifs.
Architecture retenue : trois nœuds, un quorum
Le nombre de nœuds n’est pas un détail : Galera repose sur un mécanisme de quorum qui exige qu’une majorité stricte de nœuds reste joignable pour continuer à accepter des écritures, ce qui évite un scénario de « split-brain » où deux moitiés du cluster accepteraient des écritures divergentes. Un cluster à deux nœuds ne peut pas établir de majorité en cas de coupure entre eux ; trois nœuds constituent le minimum pratique.
cluster-percona/
├── noeud1 (10.0.1.11) — datacenter A
├── noeud2 (10.0.1.12) — datacenter A
└── noeud3 (10.0.1.13) — datacenter B (quorum de secours)
Équilibreur de charge (HAProxy)
└── répartit les écritures WordPress vers un nœud sain
Pour ce client, deux nœuds ont été placés dans le même datacenter (latence minimale entre eux) et un troisième dans un second datacenter, dédié essentiellement au maintien du quorum en cas de panne complète du premier site — une architecture qui tolère la perte d’un nœud, voire d’un datacenter entier, sans interruption des écritures.
Ce que ça change côté configuration WordPress
WordPress ne doit jamais pointer directement vers l’un des trois nœuds du cluster dans son fichier wp-config.php : une panne de ce nœud précis provoquerait une interruption totale, malgré la disponibilité des deux autres. La connexion doit systématiquement transiter par un équilibreur de charge (HAProxy, dans ce déploiement), qui vérifie l’état de santé de chaque nœud et ne route le trafic que vers ceux réellement synchronisés.
define( 'DB_HOST', '127.0.0.1:3306' ); // HAProxy local, jamais un nœud direct
HAProxy a été configuré pour interroger un script de vérification de santé (clustercheck, fourni par Percona) toutes les deux secondes sur chaque nœud, retirant automatiquement de la rotation tout nœud dont l’état Galera passerait en désynchronisation.
Les limites à connaître avant de se lancer
Percona XtraDB Cluster ne convient pas à toutes les charges : les tables sans clé primaire explicite posent problème avec Galera (verrouillage à l’échelle du cluster plutôt que de la ligne), et les très grosses transactions écrites d’un coup ralentissent l’ensemble du cluster, la certification devant attendre la réplication complète de la transaction. WordPress, avec ses tables généralement bien indexées, s’en accommode bien, à condition d’auditer les plugins tiers qui créent parfois des tables sans clé primaire.
Un cluster à trois nœuds sans supervision de son état de synchronisation n’apporte aucune garantie réelle : la haute disponibilité se vérifie en continu, elle ne se décrète pas à l’installation.
En résumé
Percona XtraDB Cluster apporte une haute disponibilité réelle pour une base MySQL critique, à condition d’accepter la complexité opérationnelle qui l’accompagne : trois nœuds minimum, un équilibreur de charge devant, une supervision de l’état Galera de chaque membre. Pour un WordPress qui ne tolère aucune coupure de vente, cet investissement d’architecture reste largement justifié face au coût d’une interruption, même brève.
