# Répliquer des bases de données MySQL

> Maître-esclave, maître-maître, Group Replication, InnoDB Cluster, Vitess : les méthodes de réplication MySQL, leurs compromis et leurs bonnes pratiques.

- Date : 2020-11-17
- Lecture : 9 min
- Catégorie : data
- Tags : MySQL, Data, Réplication, Haute disponibilité, Group Replication, Base de données, Failover, InnoDB
- URL : https://www.adservio.fr/insights/articles/repliquer-des-bases-mysql

## L'essentiel

- La réplication MySQL copie les données d'un serveur vers un ou plusieurs autres afin d'améliorer la disponibilité et les performances.
- La réplication maître-esclave dirige toutes les écritures vers un serveur maître et répartit les lectures sur des esclaves, mais le basculement reste manuel.
- La réplication maître-maître ajoute plusieurs maîtres pour faire évoluer les écritures et renforcer la redondance, au prix d'un basculement semi-manuel.
- Le Group Replication, plugin de MySQL, offre un basculement automatique et une résolution de conflits intégrée, mais reste limité à neuf nœuds et exclusif à MySQL.
- InnoDB Cluster et ClusterSet ajoutent l'orchestration et la reprise après sinistre multi-site, tandis que Vitess permet le sharding horizontal à très grande échelle.
- Les bonnes pratiques consistent à s'appuyer sur les GTID, la réplication semi-synchrone, à éviter les grosses mises à jour en cours de réplication et à ne pas utiliser de tables en mémoire, non persistantes.

## Pourquoi et comment répliquer une base MySQL

Répliquer une base de données MySQL consiste à copier ses données vers un ou plusieurs autres serveurs, afin de gagner en disponibilité et de mieux répartir la charge. Selon les objectifs visés, plusieurs stratégies existent, chacune avec ses avantages et ses limites.

Plusieurs méthodes principales se dégagent : la réplication maître-esclave, la réplication maître-maître, le Group Replication, et les architectures plus intégrées comme InnoDB Cluster ou le sharding avec Vitess. Le bon choix dépend du besoin de faire évoluer les lectures, les écritures, d'automatiser le basculement en cas de panne, ou de répartir la base sur plusieurs sites géographiques.

Ce choix n'est pas qu'une décision technique isolée : il engage la façon dont les équipes exploitent la base au quotidien, les outils de supervision à mettre en place et le niveau de compétence interne nécessaire pour diagnostiquer un incident de réplication en pleine nuit. Une topologie trop sophistiquée pour l'équipe qui doit l'opérer devient vite un risque en soi, aussi robuste soit-elle sur le papier : la meilleure architecture est celle que l'organisation est capable de comprendre, de surveiller et de réparer sous pression, pas nécessairement la plus avancée techniquement.

## La réplication maître-esclave

C'est la méthode fondatrice. Un serveur maître unique reçoit toutes les requêtes de lecture et d'écriture, tandis qu'au moins un serveur esclave, en lecture seule, reçoit les données de manière asynchrone. Cette répartition des requêtes entre maître et esclaves améliore les performances globales, sans restriction de performance sur le serveur.

Le revers tient à la nature asynchrone de la réplication, qui réduit la fiabilité : en cas de défaillance du maître, des transactions destinées à l'esclave peuvent être perdues. Faire évoluer les écritures suppose par ailleurs d'augmenter les ressources du nœud maître, et le basculement reste un processus manuel.

Ce schéma reste néanmoins très utilisé pour des usages précis : isoler les requêtes de reporting ou d'analytique sur un esclave dédié, sans impacter les performances des transactions applicatives sur le maître, ou fournir une base en lecture seule à des services qui n'ont pas besoin d'écrire. C'est souvent le premier niveau de réplication mis en place avant d'envisager des architectures plus élaborées.

## La réplication maître-maître

Cette approche plus évoluée requiert au moins deux nœuds maîtres, chacun assurant les lectures et les écritures, avec une réplication asynchrone entre eux. Elle permet de faire évoluer les écritures en ajoutant des maîtres et renforce la redondance ; la présence de plusieurs maîtres réduit le risque de défaillance simultanée et rend le basculement semi-automatique.

Ses limites restent proches de celles du maître-esclave : des transactions peuvent être perdues lors de la panne d'un maître, et les données de sauvegarde risquent d'être incohérentes d'un nœud à l'autre. Le basculement demande souvent une intervention semi-manuelle, susceptible de promouvoir un nœud esclave. Le risque le plus spécifique au maître-maître reste celui des écritures concurrentes sur la même ligne depuis deux maîtres différents : sans discipline applicative claire, par exemple en dirigeant systématiquement l'écriture d'une même clé vers le même maître, ces conflits peuvent produire des divergences silencieuses entre les nœuds.

> À lire aussi : [Patterns de haute disponibilité PostgreSQL](https://www.adservio.fr/insights/articles/patterns-haute-disponibilite-postgresql): Patroni, PgPool-II, PAF, CloudNativePG : comparatif des patterns de haute disponibilité PostgreSQL en 2026, réplication, basculement automatique, RTO/RPO et bonnes pratiques.

## GTID et réplication semi-synchrone : fiabiliser la chaîne

### Le rôle des GTID dans la traçabilité des transactions

Les GTID (Global Transaction Identifiers) attribuent un identifiant unique à chaque transaction validée, y compris à travers plusieurs serveurs et plusieurs générations de topologie. Cette traçabilité simplifie considérablement les reprises après incident : au lieu de rechercher manuellement une position précise dans un fichier binlog et un décalage d'octets, l'administrateur demande simplement au serveur de rattraper les transactions manquantes par identifiant, ce qui réduit fortement le risque d'erreur humaine lors d'un basculement sous pression. Les GTID sont aujourd'hui un prérequis de fait pour la plupart des outils d'automatisation de topologie, car ils permettent de reconstruire une chaîne de réplication cohérente sans connaître l'historique complet de chaque nœud.

### La réplication semi-synchrone pour réduire la fenêtre de perte

La réplication purement asynchrone n'offre aucune garantie qu'une transaction validée sur le maître ait effectivement atteint un esclave avant une panne. La réplication semi-synchrone comble une partie de cet écart : le maître attend qu'au moins un esclave ait accusé réception de la transaction avant de confirmer l'écriture au client, ce qui réduit la fenêtre de perte de données sans imposer le coût de latence d'une réplication totalement synchrone. Ce compromis en fait un choix par défaut raisonnable pour la plupart des architectures critiques qui ne peuvent se permettre ni la lenteur du synchrone strict, ni le risque du tout-asynchrone. En pratique, on associe souvent le semi-synchrone aux GTID pour obtenir à la fois une garantie de durabilité minimale et une reprise après incident simplifiée, ce qui explique pourquoi cette combinaison est devenue la base recommandée avant même d'envisager Group Replication.

## Le Group Replication et les bonnes pratiques

### Le plugin Group Replication

Le Group Replication est une fonctionnalité fournie sous forme de plugin du serveur MySQL. Fondé sur une architecture de machine à états distribuée, il crée un système tolérant aux pannes avec résolution automatique des conflits : le système reste disponible malgré la défaillance d'une minorité de nœuds, le basculement est automatique et un maître de remplacement est élu par le groupe. Il autorise une mise à l'échelle des lectures comme des écritures, sans limitation de performance, mais reste plafonné à neuf nœuds et exclusif à MySQL, donc indisponible pour des forks comme Percona ou MariaDB, une limite toujours en vigueur avec MySQL 9.7 LTS, la version long-term support actuelle.

### Bonnes pratiques opérationnelles

Quelques bonnes pratiques s'imposent. Il faut éviter les grosses mises à jour pendant la réplication : les traitements par lots génèrent une activité excessive qui bloque les flux, d'où l'intérêt de la réplication parallèle. Il convient aussi d'éviter les tables en mémoire, non persistantes, qui perdent leurs données au redémarrage de MySQL et provoquent des erreurs de réplication ; la solution consiste à copier ces données et à basculer sur InnoDB. Enfin, s'entourer d'experts évite des erreurs coûteuses.

> À lire aussi : [Le Database-as-a-Service (DBaaS)](https://www.adservio.fr/insights/articles/database-as-a-service-dbaas): Le Database-as-a-Service (DBaaS) permet d'exploiter une base de données sans l'administrer : hébergement managé, facturation à l'usage et sécurité déléguée.

## InnoDB Cluster, ClusterSet et mise à l'échelle avec Vitess

### InnoDB Cluster et ClusterSet pour la reprise après sinistre

InnoDB Cluster assemble Group Replication, le routeur MySQL Router et les outils d'administration MySQL Shell en une solution de haute disponibilité intégrée, avec un objectif de perte de données nul (RPO=0) et un temps de reprise typique de trente à soixante secondes. InnoDB ClusterSet va plus loin en reliant un cluster primaire à une ou plusieurs répliques situées dans d'autres centres de données, avec une réplication dédiée entre clusters : en cas de sinistre régional touchant le site primaire, une bascule vers un cluster répliqué devient possible sans reconstruire toute la topologie depuis zéro.

### Vitess et le sharding horizontal pour l'échelle

Quand le volume de données ou le débit d'écriture dépasse ce qu'un seul cluster MySQL peut absorber, même avec des maîtres multiples, le sharding horizontal devient nécessaire. Vitess, utilisé notamment par des plateformes comme YouTube, Slack ou Pinterest à très grande échelle, répartit les données sur de nombreux fragments MySQL tout en exposant une interface unique aux applications, masquant la complexité du routage des requêtes vers le bon fragment. Cette approche répond à un besoin différent de la haute disponibilité classique : elle vise la scalabilité horizontale plutôt que la seule tolérance aux pannes, et s'adresse surtout aux organisations dont la croissance dépasse ce qu'une verticalisation du matériel peut encore absorber.

### Orchestrator, ProxySQL et l'observabilité de la réplication

Quelle que soit l'architecture retenue, sa fiabilité en production dépend autant de l'outillage d'exploitation que de la topologie elle-même. Des outils comme Orchestrator pour la détection de panne et la promotion automatique, ou ProxySQL pour le routage transparent des requêtes de lecture et d'écriture, complètent utilement Group Replication ou une topologie maître-esclave classique. MySQL 9.7 LTS a d'ailleurs enrichi les capacités natives d'observabilité de la réplication en édition Community, avec davantage de métriques et une meilleure visibilité sur le comportement du Group Replication, réduisant la dépendance à des outils tiers pour le simple diagnostic quotidien.

## L'approche Adservio

Chez Adservio, nous choisissons une méthode de réplication en fonction de ce que l'architecture doit réellement garantir : distribution des lectures, montée en charge des écritures, automatisation du basculement ou scalabilité horizontale à très grande échelle. Aucune méthode n'est universelle, chacune impose ses compromis entre fiabilité, cohérence et complexité opérationnelle. Nous évaluons systématiquement le niveau de maturité opérationnelle de l'équipe qui devra exploiter la solution au quotidien avant de recommander une architecture, car une topologie mal maîtrisée en interne finit toujours par coûter plus cher que le gain de disponibilité qu'elle promettait.

Notre conviction : une réplication robuste se conçoit en amont, en tenant compte des pièges courants comme les traitements par lots ou les tables non persistantes, et en s'appuyant sur des fondations solides comme les GTID et la réplication semi-synchrone plutôt que sur des rustines ajoutées après un premier incident. Nous accompagnons vos équipes dans le choix et la mise en place de la bonne stratégie, de l'audit de l'existant jusqu'au run en production, puis leur transférons la maîtrise pour exploiter durablement leurs bases MySQL en autonomie.

## FAQ

### Quelles sont les méthodes de réplication MySQL ?

Plusieurs méthodes principales : la réplication maître-esclave (écritures sur le maître, lectures réparties sur les esclaves), la réplication maître-maître (plusieurs maîtres pour faire évoluer les écritures), le Group Replication (basculement automatique et résolution de conflits intégrée), InnoDB Cluster/ClusterSet (orchestration et reprise après sinistre multi-site) et Vitess (sharding horizontal à très grande échelle).

### Quelle est la limite du Group Replication ?

Il est plafonné à neuf nœuds maximum et reste exclusif à MySQL : il n'est pas disponible pour des forks comme Percona ou MariaDB.

### À quoi servent les GTID et la réplication semi-synchrone ?

Les GTID identifient chaque transaction de façon unique et simplifient les reprises après incident. La réplication semi-synchrone réduit la fenêtre de perte de données en attendant qu'au moins un esclave ait accusé réception avant de confirmer l'écriture, sans le coût de latence d'une réplication totalement synchrone.

### Quelles bonnes pratiques pour une réplication fiable ?

Éviter les grosses mises à jour pendant la réplication (préférer la réplication parallèle), éviter les tables en mémoire non persistantes en basculant sur InnoDB, s'appuyer sur les GTID et le semi-synchrone, et s'entourer d'experts pour prévenir les erreurs coûteuses.