Réplication MySQL : guide de configuration maître-réplica

À mesure qu'un serveur de jeu ou une application web très sollicitée grandit, une base de données unique peine à supporter seule toute la charge de lecture et d'écriture. La réplication MySQL permet de répartir cette charge en copiant tes données d'un serveur principal (master) vers une ou plusieurs copies (replica/slave) en quasi temps réel : les écritures vont vers le master, tandis que les requêtes de lecture lourdes sont distribuées entre les réplicas. Dans ce guide, tu vas construire une architecture maître-réplica de zéro, utiliser l'approche moderne basée sur GTID et apprendre à surveiller la santé de ton réplica.

Comment fonctionne la réplication ?

Au cœur de la réplication MySQL se trouve le binary log (binlog). Chaque opération modifiant les données sur le master (INSERT, UPDATE, DELETE, DDL) est écrite dans le binlog. Le réplica se connecte au master, copie ce journal dans son propre relay log, puis rejoue les événements sur lui-même. Le processus s'appuie sur deux threads :

• Thread I/O : lit le binlog du master et l'écrit dans le relay log du réplica.
• Thread SQL (applier) : applique les événements du relay log aux données du réplica.

La réplication par défaut est asynchrone : le master valide sa transaction sans attendre que le réplica reçoive l'événement. Le réplica peut donc accuser quelques secondes de retard sur le master, ce que l'on appelle replication lag. En être conscient est essentiel lorsque tu conçois la distribution des lectures.

Configurer le serveur master

La première étape consiste à activer le binary log sur le master et à donner au serveur une identité unique. Chaque nœud de réplication doit avoir un server_id unique sur tout le réseau. Ajoute ceci dans la section [mysqld] de ton fichier my.cnf :

[mysqld]
server_id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
bind_address = 0.0.0.0

binlog_format = ROW enregistre les changements ligne par ligne et est bien plus fiable que le mode STATEMENT. gtid_mode = ON active la réplication moderne basée sur GTID, qui automatise la gestion des positions. Redémarre le service après la modification :

sudo systemctl restart mysql

Crée ensuite un utilisateur dédié auquel le réplica se connectera. Ne lui accorde que le privilège REPLICATION SLAVE ; n'attribue pas de droits étendus :

CREATE USER 'repl'@'%' IDENTIFIED BY 'MotDePasseFort!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

Transférer les données existantes vers le réplica

Avant de pouvoir rattraper le master, le réplica doit partir du même point que les données existantes. La façon la plus propre de prendre un instantané cohérent est mysqldump. Avec GTID activé, l'ensemble GTID de départ est intégré directement dans le dump :

mysqldump --all-databases --single-transaction \
  --source-data=2 --triggers --routines --events \
  -u root -p > sauvegarde-complete.sql

--single-transaction prend un instantané cohérent des tables InnoDB sans les verrouiller, et --source-data=2 ajoute la position du binlog en commentaire. Copie le fichier sur le réplica et importe-le :

scp sauvegarde-complete.sql utilisateur@ip-replica:/tmp/
# sur le réplica :
mysql -u root -p < /tmp/sauvegarde-complete.sql

Connecter le serveur réplica

Dans le my.cnf du réplica, donne-lui un server_id différent, et envisage de le passer en lecture seule pour qu'une écriture accidentelle ne casse pas la réplication :

[mysqld]
server_id = 2
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON
super_read_only = ON
relay_log = /var/log/mysql/relay-bin.log

Après avoir redémarré le service, pointe le réplica vers le master. Dans MySQL 8, les commandes modernes utilisent la terminologie SOURCE :

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.0.1',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'MotDePasseFort!',
  SOURCE_AUTO_POSITION = 1;

START REPLICA;

Grâce à GTID, SOURCE_AUTO_POSITION = 1 permet au réplica de reprendre au bon endroit sans que tu aies à saisir manuellement le nom du fichier binlog et la position. Dans les versions plus anciennes, l'équivalent est CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1 suivi de START SLAVE.

Surveiller et dépanner la réplication

Pour vérifier que le réplica fonctionne réellement, interroge son état :

SHOW REPLICA STATUS\G

Porte une attention particulière à ces trois champs dans la sortie :

• Replica_IO_Running: Yes et Replica_SQL_Running: Yes — les deux threads doivent être en marche.
• Seconds_Behind_Source — le nombre de secondes de retard du réplica sur le master. S'il ne cesse de grimper, le réplica n'arrive pas à suivre la charge.
• Last_Error — s'il n'est pas vide, le thread SQL s'est bloqué en appliquant un événement.

Les causes de lag les plus fréquentes sont les disques lents, les index manquants sur le réplica et l'application mono-thread. Dans MySQL 8, tu peux appliquer les événements en parallèle en augmentant replica_parallel_workers :

SET GLOBAL replica_parallel_workers = 4;

Si tu veux des garanties de cohérence plus fortes, tu peux activer la réplication semi-synchrone ; dans ce mode, le master ne confirme un commit qu'une fois qu'au moins un réplica a écrit l'événement dans son relay log. Tu dois installer et activer le plugin :

INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;

Répartir la charge de lecture

Tout l'intérêt de la réplication est de diviser la charge. Garde deux pools de connexions dans ton application : les écritures et les requêtes sensibles à la cohérence comme SELECT ... FOR UPDATE vont vers le master, tandis que les lectures lourdes comme les rapports et les listings vont vers les réplicas. Des frameworks comme Laravel le prennent en charge au niveau de la configuration :

'mysql' => [
  'read'  => ['host' => ['10.0.0.2']],
  'write' => ['host' => ['10.0.0.1']],
  'sticky' => true,
],

sticky => true est un détail crucial : si tu as effectué une écriture dans la même requête, il dirige aussi les lectures suivantes vers le master, ce qui t'évite de lire des données pas encore visibles sur le réplica à cause du lag.

Questions fréquentes

La réplication équivaut-elle à une sauvegarde ?

Non. Comme le réplica répète chaque opération du master, il supprime aussi instantanément une table que tu as effacée par erreur. La réplication sert à la haute disponibilité et à la répartition de charge ; pour la récupération de données, il te faut toujours des mysqldump réguliers ou des sauvegardes physiques.

Puis-je ajouter plus d'un réplica ?

Oui. Un master peut alimenter plusieurs réplicas ; il suffit de donner à chacun un server_id différent et de répéter les mêmes étapes de configuration. C'est la méthode la plus courante pour faire passer les lectures à l'échelle horizontalement.

Que faire si le réplica prend du retard sur le master ?

Surveille d'abord Seconds_Behind_Source. En cas de lag persistant, accélère le disque du réplica (SSD/NVMe), augmente le nombre de workers d'application parallèles et ajoute les index manquants sur le réplica. Découper les grosses écritures en lots plus petits réduit aussi nettement le lag.

Ne laisse pas la couche base de données te ralentir à mesure que tu montes en charge. Si tu veux concevoir une architecture de réplication MySQL hautement disponible pour ton serveur de jeu ou ton projet web, contacte-moi et nous la mettrons en place ensemble.