Types de réplication MySQL : avantages et inconvénients

Types de réplication MySQL : avantages et inconvénients

Vous gérez une base de données MySQL critique. Votre infrastructure a besoin de haute disponibilité. Mais quelle stratégie de réplication choisir ?

Il existe quatre approches principales :

• Master-Slave (réplication simple et unidirectionnelle)
• Master-Master (réplication bidirectionnelle)
• MySQL Group Replication (réplication synchrone native)
• Galera Cluster (clustering distribué)

Chacune a ses forces et ses faiblesses. Chacune a un coût opérationnel différent.

Cet article compare ces quatre options et montre comment les déployer sur Kubernetes avec Hikube.

Master-Slave : simple mais risqué

Principe : Un serveur principal (master) reçoit les écritures. Les serveurs secondaires (slaves) répliquent les données de façon asynchrone.

Avantages

• Simplicité : Facilement mis en place. Un master, N slaves. Configuration straightforward.
• Scalabilité des lectures : Distribuez les lectures sur plusieurs slaves. Si vous avez 100 requêtes/sec de lecture, vous pouvez les distribuer sur 3-5 slaves.
• Coût bas : Peu d'overhead. La réplication asynchrone ne consomme pas beaucoup de ressources.
• Flexibilité : Vous pouvez arrêter un slave pour faire du backup sans impacter les autres.

Inconvénients

• Réplication asynchrone : Entre le moment où le master écrit et où le slave réplique, il y a un délai (millisecondes à secondes). Si le master crash pendant ce délai, les écritures non répliquées sont perdues.
• Pas de failover automatique : Si le master crash, quelqu'un doit promouvoir manuellement un slave en master. Cela prend du temps et peut créer de la confusion (quel slave était le plus à jour ?).
• Pas de scalabilité d'écriture : Toutes les écritures vont au master. Vous ne pouvez pas distribuer les écritures sur plusieurs serveurs.
• Un point de défaillance : Un master down = pas d'écritures du tout, même si les slaves sont vivants.

Cas d'usage appropriés

• Applications avec peu d'écritures critiques
• Haute tolérance à une perte de données mineure (quelques secondes)
• Équipes sans expertise en HA de bases de données
• Budgets très limités

Master-Master : réplication bidirectionnelle

Principe : Deux masters se répliquent mutuellement. Les écritures peuvent aller sur n'importe lequel.

Avantages

• Failover semi-automatique : Si master-1 crash, les applications peuvent rediriger vers master-2 sans intervention manuelle.
• Scalabilité d'écriture horizontale : Vous pouvez écrire sur master-1 OU master-2. Potentiellement, double la capacité d'écriture.
• Haute disponibilité active-active : Les deux serveurs sont actifs. Aucun n'est en attente.

Inconvénients

• Conflits de réplication : Si vous écrivez le même enregistrement sur les deux masters simultanément (même ID), que se passe-t-il ? Réplication asynchrone = chaos potentiel. Vous avez besoin de stratégies de conflict resolution (last write wins, custom handlers, etc.).
• Inconsistance temporaire : Parce que la réplication est asynchrone, master-1 et master-2 peuvent temporairement avoir des données différentes.
• Complexité augmentée : Le debugging devient plus difficile. Est-ce que les données sont inconsistentes parce qu'il y a un bug d'application ou un problème de réplication ?
• Backup compliqué : Faire un backup cohérent de deux serveurs qui se répliquent l'un l'autre est très difficile. Vous risquez de backup un état incohérent.

Cas d'usage appropriés

• Applications tolérant une eventual consistency
• Multi-région (écrire localement, répliquer globalement)
• Systèmes de cache où la perte de données est acceptable
• Architectures où le failover manuel est inacceptable

MySQL Group Replication : synchrone et automatique

Principe : MySQL Group Replication (MGR) est un plugin MySQL natif qui gère la réplication synchrone. Multiples serveurs dans un groupe. Les écritures sont repliquées de manière synchrone avant d'être commitées.

Avantages

• Réplication synchrone : Les écritures ne sont commitées que quand la majorité du groupe l'a confirmée. Zéro perte de données.
• Failover automatique : Si un nœud crash, le groupe l'expulse et élit un nouveau coordinateur. Les applications voient un failover quasi-instantané.
• Nombre minimal de nœuds : Minimum 3 noeuds pour un cluster résilient (le quorum exige une majorité pour tolérer une panne).
• Intégré à MySQL : Pas de logiciel externe. Pas de dépendances à gérer.

Inconvénients

• MySQL only : MGR ne fonctionne que sur MySQL. Si vous utilisez MariaDB ou Percona, ce n'est pas disponible.
• Limite de 9 nœuds : Au-delà de 9 nœuds, les performances se dégradent significativement parce que chaque écriture doit être synchronisée par les 9 nœuds.
• Overhead de réplication synchrone : Les écritures sont plus lentes parce qu'elles attendent la confirmation du groupe. Attendez une latence de 10-50ms par écriture supplémentaire.
• Pas de scaling de lecture horizontale : Contrairement à Master-Slave, vous n'avez pas d'avantage réel à ajouter des nœuds en lecture seule. Tous les nœuds sont égaux.

Cas d'usage appropriés

• Applications exigeant une cohérence totale
• Infrared où l'automatisation du failover est critique
• Déploiements sur Kubernetes (MGR s'adapte bien aux StatefulSets)
• Organisations utilisant MySQL (pas MariaDB)

Galera Cluster : clustering distribué

Principe : Galera Cluster utilise le protocole Galera pour la réplication synchrone. Compatible avec MariaDB et MySQL (via Percona XtraDB Cluster).

Avantages

• Réplication synchrone vraie : Comme MGR, mais implémenté différemment. Zéro perte de données.
• Vrai clustering : Tous les nœuds sont égaux. Vous pouvez écrire sur n'importe lequel. Failover est par défaut.
• Quorum automatique : Si vous perdez la majorité des nœuds, le cluster s'arrête pour éviter les divergences (split-brain).
• Compatible MariaDB : Fonctionne avec MariaDB ET MySQL (via Percona).

Inconvénients

• Overhead de performance : Galera est plus exigeant que Master-Slave. Attendez 20-40% de dégradation de performance comparé à non-clustered MySQL.
• Limitation sur les transactions longues : Les transactions qui durent longtemps (> 1-2 secondes) peuvent bloquer le clustering.
• Pas avec MySQL natif : Galera fonctionne avec MariaDB et Percona XtraDB Cluster (fork de MySQL). Pas avec MySQL vanilla.
• Coûts de licence : Percona XtraDB Cluster a des versions commerciales avec support.

Cas d'usage appropriés

• Organisations utilisant MariaDB
• Besoin absolu de failover automatique AND scalabilité d'écriture
• Clusters small (3-5 nœuds)
• Infrastructure hautement résiliente

Comparatif résumé

MySQL HA sur Kubernetes : la modernité

L'approche traditionnelle (Manager une baremetal HA) est de plus en plus remplacée par le déploiement sur Kubernetes. Pourquoi ?

Kubernetes + MySQL = simplicité opérationnelle

Déployer MySQL HA sur Kubernetes (via Hikube) offre plusieurs avantages :

1. Orchestration automatique

Les MySQL Operators (comme Oracle MySQL Operator ou Percona Operator) automatisent :

• Déploiement des nœuds MySQL
• Configuration de la réplication (automatique)
• Failover automatique en cas de crash
• Scaling (ajouter des nœuds = un patch Kubernetes)

apiVersion: mysql.oracle.com/v1
kind: MySQLCluster
metadata:
  name: my-mysql-ha
spec:
  instances: 3
  replication:
    type: Group Replication
  storage:
    size: 100Gi
  backup:
    enabled: true
    schedule: "0 2 * * *"

2. StatefulSets et persistent storage

Kubernetes StatefulSets gèrent l'ordre de déploiement et les noms stables. Combiné avec persistent volumes, MySQL HA devient aussi simple qu'une application stateless.

3. Backups intégrés

Les Operators incluent souvent des backups automatiques et des stratégies de recovery.

4. Monitoring intégré

Prometheus scrape les metrics MySQL. Alertmanager vous notifie. Tout intégré dans votre stack observabilité.

Hikube et MySQL HA

Sur Hikube (Kubernetes managé par Hidora), déployer MySQL HA est simplifié :

• Infrastructure suisse : Vos données restent en Suisse
• Stockage persistant managé : Disques résilients, snapshots automatiques
• Backups et DR : Inclus dans la gestion Hikube
• Monitoring natif : Intégration Prometheus/Grafana
• Scalabilité facile : Augmentez les nœuds avec kubectl

Exemple : Créer un cluster MySQL à 3 nœuds avec MGR sur Hikube prend ~15 minutes. Le même setup en baremetal peut prendre 2-3 jours de configuration.

Quelle stratégie choisir ?

Pour une application web standard (reads > writes)

Recommendation : Master-Slave

• Déployer 1 master + 2-3 slaves
• Utiliser un load balancer qui dirige les reads vers slaves et writes vers master
• ProxySQL en frontal pour router intelligent
• Moins cher, moins complexe, parfait pour 80% des apps

Pour une application avec écritures distribuées (multi-région)

Recommendation : Master-Master ou MGR

• Si vous utilisez MySQL vanilla : MGR sur Hikube
• Si vous utilisez MariaDB : Master-Master (plus simple)
• Failover automatique à zone-level

Pour une mission critique zéro-downtime absolue

Recommendation : MySQL Group Replication sur Hikube

• 3+ nœuds dans 3 zones de disponibilité différentes
• Quorum = zéro perte de données
• Failover automatique = RTO de quelques secondes
• Opérationnel : Orchestrator + Hikube monitoring

Pour MariaDB à très haute résilience

Recommendation : Galera Cluster

• Plus complexe à opérer, mais vraiment distribué
• True multi-master write scaling
• Meilleur choix pour MariaDB critique

ProxySQL : le routeur intelligent

Quelle que soit votre stratégie, vous aurez besoin d'un routeur de connexion MySQL.

ProxySQL :

• Dirige reads vers slaves, writes vers master (pour Master-Slave)
• Load balance les connexions
• Gère les failovers gracieux
• Compatible avec tous les types de réplication

Sur Hikube, déployer ProxySQL devant votre cluster MySQL prend 2-3 minutes.

Orchestrator : gestion HA

Pour les déploiements complexes, Orchestrator automatise :

• Détection de crashes
• Promotion automatique de slaves
• Rééquilibrage de topologie

Inclus dans les offres de services managés Hidora.

En résumé

La réplication MySQL n'est plus une décision purement technique. C'est une décision d'exploitation et de coûts.

Master-Slave coûte moins cher mais demande intervention manuelle en cas de incident. MGR et Galera coûtent plus cher mais éliminent la plupart des interventions manuelles.

Sur Kubernetes via Hikube, la différence de coût diminue parce que l'orchestration est déjà gérée.

Vous managez une base de données critique ? Hidora propose des services MySQL HA sur Hikube : Services gérés · Consulting base de données · Infrastructure Kubernetes