Réplication MySQL : GTID, source-replica, Group Replication et InnoDB Cluster

Un MySQL seul est un point de défaillance unique (SPOF). Panne disque, crash système, maintenance planifiée — votre application est indisponible tant que le serveur n’est pas relancé. La réplication résout ce problème en copiant en continu les modifications vers un ou plusieurs replicas qui peuvent prendre le relais en cas de panne, absorber les lectures, ou servir de base pour les sauvegardes.

Ce guide monte un cluster source-replica avec réplication GTID asynchrone, couvre la surveillance du lag, le failover manuel, puis présente les architectures avancées : semi-synchrone, Group Replication et InnoDB Cluster.

Version actuelle

Ce guide utilise MySQL 8.4 LTS (avril 2024). Changements notables : les termes source/replica remplacent officiellement master/slave, les tagged GTIDs sont introduits, et le clone plugin simplifie l’initialisation des replicas.

Ce que vous allez apprendre

• Configurer un source et un replica en réplication GTID asynchrone de bout en bout
• Comprendre les binary logs, relay logs et positions GTID qui pilotent la réplication
• Surveiller le lag de réplication et diagnostiquer les retards
• Exécuter un failover manuel avec CHANGE REPLICATION SOURCE TO
• Distinguer réplication classique, semi-synchrone, Group Replication et InnoDB Cluster
• Choisir la bonne architecture selon vos exigences de disponibilité

Dans quel contexte ?

La réplication MySQL répond à des besoins concrets d’administration :

• Vous administrez un MySQL en production et vous voulez éliminer le point de défaillance unique (SPOF)
• Vous avez besoin d’un replica en lecture pour décharger le source des requêtes de reporting ou d’analytics
• Vous préparez une maintenance planifiée (montée de version, migration) avec basculement contrôlé
• Vous devez garantir une reprise rapide (RTO court) en cas de crash du serveur principal
• Votre application nécessite une haute disponibilité automatisée (Group Replication, InnoDB Cluster)

Ce guide ne couvre pas…

Sauvegarde et restauration mysqldump, MySQL Shell, Percona XtraBackup et PITR — complémentaire à la réplication

Monitoring et maintenance Performance Schema, slow queries, OPTIMIZE TABLE et alertes

Prérequis

• Deux serveurs avec MySQL 8.4 installé (même version) — voir le guide d’installation
• Un réseau permettant la connexion TCP entre les deux nœuds (port 3306)
• Accès root MySQL sur les deux serveurs
• Les bases du guide de configuration (notamment la section binary log)

Lab utilisé dans ce guide :

Rôle	Hostname	IP	OS	MySQL
Source	mysql-source	192.168.122.71	Debian 12	8.4 LTS
Replica	mysql-replica	192.168.122.72	Debian 12	8.4 LTS

Glissez pour voir

La réplication n’est pas une sauvegarde

Réplication ≠ sauvegarde

La réplication propage tout du source vers le replica : les INSERT mais aussi les DELETE, les DROP TABLE et les erreurs humaines. Un DROP DATABASE sur le source est immédiatement répliqué.

Pour se protéger des erreurs humaines et de la corruption, il faut des sauvegardes avec archivage binlog et PITR. Voir le guide sauvegarde-restauration.

Les trois modèles de réplication MySQL

MySQL propose trois modèles de réplication, du plus simple au plus résilient.

Réplication classique (source → replica, asynchrone)

Le modèle le plus courant. Le source écrit les modifications dans le binary log. Le replica lit ce binary log, le copie dans son relay log local, puis l’applique.

Le source n’attend pas la confirmation du replica avant de valider un COMMIT — c’est la réplication asynchrone. Simple et performante, mais quelques transactions peuvent être perdues si le source crashe avant que le replica n’ait reçu les derniers binlogs.

Semi-synchrone (plugin rpl_semi_sync)

Le source attend la confirmation du replica avant de retourner le COMMIT au client. Garantit qu’au moins un replica a reçu les données — RPO quasi nul. En contrepartie, chaque COMMIT a une latence réseau supplémentaire.

Group Replication (consensus Paxos, multi-primaire)

Plusieurs nœuds MySQL forment un groupe qui maintient la cohérence par consensus distribué (protocole Paxos). Chaque nœud peut accepter des écritures (multi-primary) ou un seul (single-primary). La détection de pannes et le failover sont automatiques.

Quand utiliser quoi

Critère	Asynchrone	Semi-synchrone	Group Replication
Complexité	Simple	Modérée	Élevée
RPO	Quelques transactions	Quasi nul	Nul (consensus)
RTO	Manuel (failover)	Manuel	Automatique
Latence COMMIT	Aucun impact	+1 aller-retour réseau	+consensus
Nombre de nœuds	2+	2+	3+ (impair recommandé)
Cas d’usage	Lecture distribuée, backup	Données critiques, finance	Haute disponibilité automatisée

Glissez pour voir

Règle pratique : commencez par la réplication GTID asynchrone. Passez en semi-synchrone pour les données critiques, et en Group Replication quand le failover automatique est indispensable.

GTID : la brique essentielle

Principe : identifiant global de transaction

Un GTID (Global Transaction Identifier) identifie de manière unique chaque transaction validée sur un serveur MySQL. Le format est source_uuid:transaction_id :

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

• source_uuid : identifiant unique du serveur qui a créé la transaction (variable server_uuid)
• transaction_id : numéro séquentiel incrémenté à chaque COMMIT

L’ensemble des GTID exécutés sur un serveur s’appelle le GTID set (visible dans gtid_executed). Lors de la réplication, le replica sait exactement quelles transactions il a déjà appliquées — il ne reçoit jamais un doublon.

Tagged GTIDs en MySQL 8.4

MySQL 8.4 introduit les tagged GTIDs au format UUID:TAG:NUMBER. Les tags permettent de catégoriser les transactions (opérations système vs applicatives) et simplifient le filtrage dans les scénarios multi-sources. Cette fonctionnalité est optionnelle et ne modifie pas le comportement par défaut.

Avantages vs réplication par position binlog

Critère	Position binlog (ancien)	GTID (recommandé)
Failover	Recalculer la position sur le nouveau source — complexe et fragile	Le replica retrouve automatiquement sa position par le GTID set
Point de reprise	Dépend du fichier + offset dans le binlog	Identifiant global — indépendant du fichier
Multi-source	Très complexe	Géré nativement (chaque source a son UUID)
Détection de doublons	Impossible	Le replica refuse les GTID déjà appliqués
Recommandation	Legacy, pour compatibilité	Standard moderne — recommandé

Glissez pour voir

Configurer le source

La configuration du source se fait en quatre étapes : paramètres serveur, GTID, rôle dédié et autorisation réseau.

Activer le binary log et les GTID

Éditez /etc/mysql/mysql.conf.d/mysqld.cnf sur le source :

[mysqld]
# Identifiant unique du serveur — DOIT être différent sur chaque nœud
server_id = 1

# Binary log (activé par défaut en 8.4, mais nommage explicite)
log_bin = /var/lib/mysql/binlog

# GTID obligatoire
gtid_mode = ON
enforce_gtid_consistency = ON

# Format ROW pour la cohérence (défaut en 8.4)
binlog_format = ROW

# Durabilité maximale
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

# Rétention binlog (30 jours)
binlog_expire_logs_seconds = 2592000

Redémarrez MySQL :

sudo systemctl restart mysql

Vérification :

SHOW VARIABLES LIKE 'gtid_mode';
SHOW VARIABLES LIKE 'enforce_gtid_consistency';
SHOW VARIABLES LIKE 'server_id';

+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| gtid_mode                | ON    |
+--------------------------+-------+

+--------------------------+-------+
| enforce_gtid_consistency | ON    |
+--------------------------+-------+

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 1     |
+---------------+-------+

server_id unique et non nul

Chaque serveur du cluster de réplication doit avoir un server_id unique et supérieur à 0. Si deux serveurs partagent le même ID, la réplication ne fonctionne pas. Convention : 1 pour le source, 2 pour le premier replica, 3 pour le deuxième, etc.

Créer un rôle REPLICATION SLAVE dédié

Ne pas utiliser le compte root pour la réplication. Créez un rôle dédié avec les seuls privilèges nécessaires :

CREATE USER 'replicator'@'192.168.122.72' IDENTIFIED BY 'motdepasse_fort_replication';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'192.168.122.72';

Le privilège REPLICATION SLAVE ne permet que la lecture du binary log — pas d’accès aux données.

Identifiants stockés en clair sur le replica

Les identifiants du compte de réplication sont stockés en clair dans le repository de métadonnées de réplication côté replica (mysql.slave_master_info). Créez un compte dédié avec le strict minimum de privilèges et protégez la connexion avec TLS en production.

Différence avec PostgreSQL

En PostgreSQL, le rôle de réplication a l’attribut REPLICATION et on autorise la connexion via une ligne replication dans pg_hba.conf. En MySQL, le privilège REPLICATION SLAVE joue le même rôle, et l’autorisation réseau passe par le @host dans CREATE USER.

Autoriser la connexion du replica

Si bind_address est à 127.0.0.1, le replica ne peut pas se connecter. Modifiez le source :

[mysqld]
bind_address = 0.0.0.0

Après redémarrage, vérifiez que MySQL écoute sur toutes les interfaces :

ss -tlnp | grep 3306

LISTEN  0  151  0.0.0.0:3306  0.0.0.0:*  users:(("mysqld",pid=1234,fd=33))

Initialiser le replica

Configurer le replica

Éditez /etc/mysql/mysql.conf.d/mysqld.cnf sur le replica :

[mysqld]
# Identifiant unique — différent du source
server_id = 2

# GTID obligatoire
gtid_mode = ON
enforce_gtid_consistency = ON

# Le replica en lecture seule
read_only = ON
super_read_only = ON

# Binary log activé (utile pour la chaîne de réplication ou le failover)
log_bin = /var/lib/mysql/binlog

# Relay log
relay_log = /var/lib/mysql/relay-bin

# Applier multi-thread (accélère le rattrapage)
replica_parallel_workers = 4
replica_parallel_type = LOGICAL_CLOCK
replica_preserve_commit_order = ON

Redémarrez MySQL sur le replica :

sudo systemctl restart mysql

Clone plugin : copie à chaud simplifiée

Le clone plugin (intégré à MySQL 8.0+) copie l’intégralité du data directory depuis le source vers le replica — c’est l’équivalent MySQL de pg_basebackup -R pour PostgreSQL.

1. Installer le plugin sur le source ET le replica :

   INSTALL PLUGIN clone SONAME 'mysql_clone.so';

2. Créer un utilisateur clone sur le source (donor) :

   CREATE USER 'clone_user'@'192.168.122.72' IDENTIFIED BY 'motdepasse_clone';
   GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'192.168.122.72';

3. Accorder CLONE_ADMIN au compte qui exécutera le clonage sur le replica (recipient) :

   -- Sur le replica
   GRANT CLONE_ADMIN ON *.* TO 'root'@'localhost';

4. Configurer le donor sur le replica :

   SET GLOBAL clone_valid_donor_list = '192.168.122.71:3306';

   Le clonage efface les données du recipient

   Le clonage distant supprime les données utilisateur et les binary logs du recipient avant la copie. Le serveur recipient redémarre automatiquement à la fin de l’opération. N’exécutez cette commande que sur un serveur que vous êtes prêt à réinitialiser.

5. Lancer le clonage depuis le replica :

   CLONE INSTANCE FROM 'clone_user'@'192.168.122.71':3306
   IDENTIFIED BY 'motdepasse_clone';

   Le replica redémarre automatiquement avec les données du source.

Alternative : mysqldump ou MySQL Shell

Si le clone plugin n’est pas disponible, initialisez le replica avec mysqldump :

mysqldump -u root -p --all-databases --single-transaction \
  --routines --triggers --events --set-gtid-purged=ON \
  -h 192.168.122.71 > /tmp/source_dump.sql

mysql -u root -p < /tmp/source_dump.sql

Ou avec MySQL Shell util.dumpInstance() / util.loadDump() pour un transfert parallèle.

CHANGE REPLICATION SOURCE TO avec GTID

Une fois les données synchronisées (clone, dump ou snapshot), configurez la réplication sur le replica :

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '192.168.122.71',
  SOURCE_PORT = 3306,
  SOURCE_USER = 'replicator',
  SOURCE_PASSWORD = 'motdepasse_fort_replication',
  SOURCE_AUTO_POSITION = 1,
  GET_SOURCE_PUBLIC_KEY = 1;

Option	Rôle
SOURCE_HOST	Adresse du source
SOURCE_USER	Rôle de réplication
SOURCE_AUTO_POSITION = 1	Active le repositionnement automatique par GTID — pas besoin de spécifier le fichier binlog et l’offset
GET_SOURCE_PUBLIC_KEY = 1	Récupère la clé publique du source pour caching_sha2_password

Glissez pour voir

GET_SOURCE_PUBLIC_KEY vs TLS

GET_SOURCE_PUBLIC_KEY = 1 récupère la clé publique à la volée depuis le source, ce qui expose à une attaque man-in-the-middle sur la première connexion. En production, préférez une connexion TLS (SOURCE_SSL = 1) ou fournissez la clé publique localement avec SOURCE_PUBLIC_KEY_PATH.

Terminologie MySQL 8.4

Les commandes CHANGE MASTER TO, SHOW SLAVE STATUS, START SLAVE sont dépréciées depuis MySQL 8.0.22 et remplacées par CHANGE REPLICATION SOURCE TO, SHOW REPLICA STATUS, START REPLICA. Les anciennes commandes fonctionnent encore mais émettent des warnings.

START REPLICA et vérification

START REPLICA;

Vérification immédiate :

SHOW REPLICA STATUS\G

*************************** 1. row ***************************
             Replica_IO_Running: Yes
            Replica_SQL_Running: Yes
              Source_Log_File: binlog.000003
          Read_Source_Log_Pos: 1234
               Relay_Log_File: relay-bin.000002
          Exec_Source_Log_Pos: 1234
        Seconds_Behind_Source: 0
           Retrieved_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-23
            Executed_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-23

Les deux indicateurs critiques :

• Replica_IO_Running: Yes — le thread I/O reçoit les binlogs du source
• Replica_SQL_Running: Yes — le thread SQL applique les événements
• Seconds_Behind_Source: 0 — le replica est synchronisé

Vérifier la réplication

SHOW REPLICA STATUS : les colonnes clés

SHOW REPLICA STATUS\G contient plus de 60 colonnes. Voici les essentielles :

Colonne	Signification
Replica_IO_Running	Yes = thread I/O actif (lecture binlog source)
Replica_SQL_Running	Yes = thread SQL actif (application relay log)
Seconds_Behind_Source	Lag en secondes (0 = synchronisé)
Retrieved_Gtid_Set	GTID reçus du source
Executed_Gtid_Set	GTID appliqués sur le replica
Last_IO_Error	Dernière erreur du thread I/O
Last_SQL_Error	Dernière erreur du thread SQL

Glissez pour voir

performance_schema.replication_*

Pour un monitoring plus structuré, utilisez les tables performance_schema :

-- État des connexions de réplication
SELECT CHANNEL_NAME, SERVICE_STATE, SOURCE_UUID,
       LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE
FROM performance_schema.replication_connection_status;

-- État des appliers (threads parallèles)
SELECT CHANNEL_NAME, WORKER_ID, SERVICE_STATE,
       LAST_APPLIED_TRANSACTION, APPLYING_TRANSACTION
FROM performance_schema.replication_applier_status_by_worker;

Calculer le lag

Seconds_Behind_Source est la métrique la plus courante mais elle peut être imprécise (elle mesure le delta entre le timestamp de l’événement et l’heure locale). Pour un calcul plus fiable :

-- Comparer les GTID exécutés vs reçus
SELECT
  GTID_SUBTRACT(
    (SELECT Received_transaction_set
     FROM performance_schema.replication_connection_status),
    @@global.gtid_executed
  ) AS gtid_lag;

Si le résultat est vide, le replica a appliqué tous les GTID reçus — zéro lag.

Multi-threaded applier (replica_parallel_workers)

En MySQL 8.4, les replicas sont multithreadés par défaut. Le paramètre replica_parallel_workers vaut 4, avec replica_preserve_commit_order = ON.

Pour augmenter la capacité de rattrapage sur un replica très sollicité :

STOP REPLICA;
SET PERSIST replica_parallel_workers = 8;
SET PERSIST replica_preserve_commit_order = ON;
START REPLICA;

Paramètre	Défaut 8.4	Rôle
replica_parallel_workers	4	Nombre de threads d’application (0 = mono-thread)
replica_parallel_type	LOGICAL_CLOCK	Parallélise par groupe de transactions commitées en même temps sur le source
replica_preserve_commit_order	ON	Garantit que l’ordre des commits est respecté même en parallèle

Glissez pour voir

Tester la réplication en temps réel

Sur le source — insérez une ligne :

INSERT INTO lab_mysql.clients (nom, email, ville)
VALUES ('Test Replication', 'repl@example.com', 'Lyon');

Sur le replica — vérifiez immédiatement :

SELECT nom, email FROM lab_mysql.clients WHERE nom = 'Test Replication';

+------------------+------------------+
| nom              | email            |
+------------------+------------------+
| Test Replication | repl@example.com |
+------------------+------------------+

La ligne est visible quasi instantanément.

Lectures sur le replica

read_only et super_read_only

Le replica est configuré en lecture seule via deux paramètres :

SHOW VARIABLES LIKE '%read_only%';

+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| read_only             | ON    |
| super_read_only       | ON    |
+-----------------------+-------+

• read_only = ON : bloque les écritures pour les utilisateurs normaux
• super_read_only = ON : bloque aussi les écritures pour les comptes avec SUPER ou CONNECTION_ADMIN — recommandé pour éviter les écritures accidentelles par un DBA

Toute tentative d’écriture est refusée :

INSERT INTO lab_mysql.clients (nom, email, ville)
VALUES ('Test', 'test@example.com', 'Paris');

ERROR 1290 (HY000): The MySQL server is running with the
--super-read-only option so it cannot execute this statement

Connecter les applications en lecture

Pour distribuer les lectures, configurez vos applications pour envoyer les écritures au source et les lectures au replica :

• Au niveau applicatif : deux connexions (source pour write, replica pour read)
• Avec un proxy : ProxySQL ou MySQL Router fait le routage automatiquement selon le type de requête

Attention au lag

Juste après une écriture sur le source, la donnée peut ne pas être encore visible sur le replica (lag asynchrone). Pour les lectures qui doivent voir les données fraîches (“read-your-writes”), lisez le source.

Failover manuel

Le failover consiste à promouvoir le replica en nouveau source quand l’ancien source est indisponible.

Le failover nécessite une reconfiguration

Contrairement à PostgreSQL (pg_promote() en une commande), le failover MySQL nécessite plusieurs étapes : arrêter la réplication, désactiver le read-only, reconfigurer les applications. La procédure est plus manuelle mais le GTID simplifie considérablement le repositionnement.

Vérifier l’état avant le failover

Avant de promouvoir, assurez-vous que le replica est synchronisé :

SHOW REPLICA STATUS\G

Vérifiez :

• Replica_IO_Running: Yes et Replica_SQL_Running: Yes
• Seconds_Behind_Source: 0
• Retrieved_Gtid_Set = Executed_Gtid_Set (tous les GTID reçus sont appliqués)

Promouvoir le replica

1. Arrêter la réplication :

   STOP REPLICA;

2. Supprimer la configuration de réplication :

   RESET REPLICA ALL;

   RESET REPLICA ALL efface toute la configuration source (host, user, etc.). Le replica oublie qu’il était un replica.

   Important : avec GTID activé, RESET REPLICA ALL ne réinitialise pas l’historique GTID (gtid_executed, gtid_purged). C’est le comportement souhaité pour le failover — le nouveau source conserve l’historique complet des transactions.

3. Désactiver le mode lecture seule :

   SET GLOBAL read_only = OFF;
   SET GLOBAL super_read_only = OFF;
   SET PERSIST read_only = OFF;
   SET PERSIST super_read_only = OFF;

4. Vérifier que les écritures fonctionnent :

   INSERT INTO lab_mysql.clients (nom, email, ville)
   VALUES ('Après failover', 'failover@example.com', 'Marseille');

   Query OK, 1 row affected

5. Reconfigurer les applications pour pointer vers le nouveau source (192.168.122.72).

Reconstruire l’ancien source comme nouveau replica

Une fois l’ancien source disponible à nouveau, reconstituez-le comme replica du nouveau source :

1. Réinitialiser les données (clone plugin ou dump depuis le nouveau source) :

   -- Sur l'ancien source
   SET GLOBAL clone_valid_donor_list = '192.168.122.72:3306';
   CLONE INSTANCE FROM 'clone_user'@'192.168.122.72':3306
   IDENTIFIED BY 'motdepasse_clone';

2. Configurer la réplication vers le nouveau source :

   CHANGE REPLICATION SOURCE TO
     SOURCE_HOST = '192.168.122.72',
     SOURCE_PORT = 3306,
     SOURCE_USER = 'replicator',
     SOURCE_PASSWORD = 'motdepasse_fort_replication',
     SOURCE_AUTO_POSITION = 1;
   
   START REPLICA;

3. Vérifier :

   SHOW REPLICA STATUS\G
   -- Replica_IO_Running: Yes
   -- Replica_SQL_Running: Yes

Réplication semi-synchrone

Principe : le COMMIT attend l’ACK du replica

En mode semi-synchrone, le source ne retourne le COMMIT au client que lorsqu’au moins un replica a confirmé avoir reçu et écrit le binlog event dans son relay log. Cela garantit que les données existent sur au moins deux serveurs avant la confirmation — RPO quasi nul.

Activer les plugins rpl_semi_sync_source / replica

1. Sur le source :

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

2. Sur le replica :

   INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
   SET GLOBAL rpl_semi_sync_replica_enabled = ON;
   SET PERSIST rpl_semi_sync_replica_enabled = ON;
   
   -- Redémarrer le thread I/O pour activer le semi-sync
   STOP REPLICA IO_THREAD;
   START REPLICA IO_THREAD;

3. Vérifier sur le source :

   SHOW STATUS LIKE 'Rpl_semi_sync_source_status';

   +-----------------------------+-------+
   | Variable_name               | Value |
   +-----------------------------+-------+
   | Rpl_semi_sync_source_status | ON    |
   +-----------------------------+-------+

Compromis : latence vs garantie de données

Paramètre	Défaut	Rôle
rpl_semi_sync_source_timeout	10000 ms	Temps d’attente avant fallback en asynchrone
rpl_semi_sync_source_wait_for_replica_count	1	Nombre de replicas devant confirmer
rpl_semi_sync_source_wait_point	AFTER_SYNC	Le COMMIT attend après l’écriture dans le binlog (avant le commit InnoDB) — loss-less semi-sync

Glissez pour voir

Fallback automatique en mode asynchrone

Si aucun replica ne confirme dans le timeout, le source bascule automatiquement en mode asynchrone pour ne pas bloquer les écritures. Il repasse en semi-synchrone dès qu’un replica se reconnecte.

-- Vérifier le nombre de fallback
SHOW STATUS LIKE 'Rpl_semi_sync_source_no_tx';
SHOW STATUS LIKE 'Rpl_semi_sync_source_yes_tx';

Un seul replica semi-synchrone = risque

Si votre unique replica tombe, le source passe en asynchrone silencieusement. Les transactions ne sont plus répliquées de manière synchrone — vous perdez la garantie RPO=0 sans notification explicite. En production, utilisez au moins deux replicas semi-synchrones.

Group Replication : aperçu

Group Replication (GR) est la solution de haute disponibilité intégrée à MySQL. Elle fournit une réplication de machine à états distribuée avec forte coordination entre nœuds. Le moteur de communication du groupe, XCom, est une variante de Paxos. La détection de pannes et le failover sont automatiques.

Single-primary vs multi-primary

Mode	Description	Cas d’usage
Single-primary	Un seul nœud accepte les écritures, les autres sont en lecture	Le plus courant, le plus simple, évite les conflits
Multi-primary	Tous les nœuds acceptent les écritures	Requiert une gestion des conflits au niveau applicatif

Glissez pour voir

Pré-requis

Group Replication impose des contraintes strictes :

• InnoDB uniquement — toutes les tables doivent utiliser InnoDB
• Clé primaire sur chaque table (pas de table sans PK)
• GTID activé (gtid_mode = ON, enforce_gtid_consistency = ON)
• Binary log en format ROW
• 3 nœuds minimum (nombre impair recommandé pour le quorum)
• Réseau fiable entre les nœuds (latence faible)

group_replication_consistency en 8.4

MySQL 8.4 change la valeur par défaut de group_replication_consistency de EVENTUAL (en 8.0) à BEFORE_ON_PRIMARY_FAILOVER — une amélioration significative de la cohérence après failover.

Valeur	Comportement
EVENTUAL	Les lectures peuvent voir des données légèrement en retard
BEFORE_ON_PRIMARY_FAILOVER	Défaut 8.4 — après un failover, le nouveau primary attend que les transactions en attente soient appliquées avant d’accepter les lectures
BEFORE	Chaque lecture attend que toutes les transactions du groupe soient appliquées
AFTER	Le COMMIT attend que tous les nœuds aient appliqué la transaction
BEFORE_AND_AFTER	Combine BEFORE et AFTER — cohérence maximale au prix de la latence

Glissez pour voir

-- Défaut en 8.4, mais peut être ajusté si besoin
SET PERSIST group_replication_consistency = 'BEFORE_ON_PRIMARY_FAILOVER';

InnoDB Cluster et InnoDB ReplicaSet : orchestration

MySQL Shell + MySQL Router + Group Replication

InnoDB Cluster combine trois composants :

1. Group Replication — le moteur de réplication sous-jacent
2. MySQL Shell (mysqlsh) — l’outil d’administration pour créer et gérer le cluster
3. MySQL Router — le proxy qui route les connexions automatiquement vers le primary (écritures) et les secondaries (lectures)

Application
    │
    ▼
MySQL Router (port 6446 R/W, port 6447 R/O)
    │
    ├── Node 1 (Primary)    ← écritures
    ├── Node 2 (Secondary)  ← lectures
    └── Node 3 (Secondary)  ← lectures

Création d’un cluster avec MySQL Shell :

// Connecté au premier nœud
var cluster = dba.createCluster('monCluster');

// Ajouter les autres nœuds
cluster.addInstance('root@192.168.122.72:3306');
cluster.addInstance('root@192.168.122.73:3306');

// Vérifier l'état
cluster.status();

InnoDB ReplicaSet : alternative simple (asynchrone)

Si Group Replication est trop contraignant, InnoDB ReplicaSet offre une orchestration simplifiée pour la réplication asynchrone classique via MySQL Shell :

var rs = dba.createReplicaSet('monReplicaSet');
rs.addInstance('root@192.168.122.72:3306');
rs.status();

// Failover
rs.setPrimaryInstance('root@192.168.122.72:3306');

Quand choisir Cluster vs ReplicaSet

Critère	InnoDB Cluster	InnoDB ReplicaSet
Réplication	Group Replication (consensus)	Asynchrone classique
Failover	Automatique	Semi-automatique (via mysqlsh)
Nombre de nœuds	3+ (impair)	2+
Contraintes	PIK obligatoire, InnoDB only	Moins contraignant
Complexité	Élevée	Modérée
Cas d’usage	HA critique en production	Réplication simple avec orchestration

Glissez pour voir

Outils tiers

Orchestrator (GitHub)

Orchestrator est un outil open source (développé par GitHub) pour la gestion et le failover automatique des topologies de réplication MySQL. Il détecte les pannes, réarrange la topologie et effectue le failover sans intervention humaine.

ProxySQL

ProxySQL est un proxy MySQL haute performance qui gère le routage lecture/écriture, le connection pooling, le query caching et le failover automatique. Alternative populaire à MySQL Router.

MySQL Router

MySQL Router est le proxy officiel Oracle, optimisé pour InnoDB Cluster. Il route les connexions en fonction du rôle (R/W → primary, R/O → secondaries) et met à jour sa configuration automatiquement quand la topologie change.

Dépannage

Symptôme	Cause probable	Solution
Replica_IO_Running: No	Connectivité réseau, credentials incorrects ou server_id dupliqué	Vérifier avec mysql -h source -u replicator -p, vérifier server_id unique
Got fatal error from source when reading data	Binlog purgé avant que le replica ne l’ait lu	Augmenter binlog_expire_logs_seconds ou reconstruire le replica (clone/dump)
Seconds_Behind_Source augmente	Le replica n’arrive pas à suivre le rythme	Activer replica_parallel_workers, vérifier les IOPS disque du replica
Duplicate entry for key 'PRIMARY'	Transaction déjà appliquée (GTID manquant)	Avec GTID, le doublon est normalement évité. Vérifier gtid_executed sur les deux nœuds
Could not find first log file name in binary log index	Le replica demande un binlog qui a été purgé	Reconstruire le replica avec le clone plugin ou un dump frais
GTID errant (errant transaction)	Transaction exécutée directement sur le replica	Identifier avec GTID_SUBTRACT(replica_gtid, source_gtid). Injecter une transaction vide sur le source pour combler, ou reconstruire le replica
Semi-sync timeout constant	Réseau lent ou replica surchargé	Vérifier la latence réseau, augmenter rpl_semi_sync_source_timeout temporairement, vérifier les IOPS
ERROR 3100 (HY000): The function is not allowed when Group Replication is running	Commande incompatible avec Group Replication	Utiliser les APIs MySQL Shell (dba.getCluster()) au lieu des commandes SQL directes

Glissez pour voir

À retenir

1. La réplication GTID est le standard en MySQL 8.4 — elle simplifie le failover en identifiant chaque transaction de manière unique
2. La réplication n’est pas une sauvegarde : un DROP TABLE est immédiatement répliqué
3. Le clone plugin simplifie l’initialisation du replica en copiant le data directory complet — c’est l’équivalent MySQL de pg_basebackup
4. CHANGE REPLICATION SOURCE TO avec SOURCE_AUTO_POSITION = 1 exploite les GTID — pas besoin de calculer la position binlog manuellement
5. read_only + super_read_only protègent le replica contre les écritures accidentelles — activez toujours les deux
6. Le multi-threaded applier (replica_parallel_workers) accélère significativement le rattrapage du replica
7. La réplication semi-synchrone garantit un RPO quasi nul mais ajoute de la latence — avec un seul replica, le fallback en asynchrone est silencieux
8. Group Replication fournit le failover automatique par consensus — impose des contraintes strictes (InnoDB, clé primaire, 3+ nœuds)
9. InnoDB Cluster = Group Replication + MySQL Shell + MySQL Router — la solution HA complète d’Oracle
10. En production, utilisez un outil d’orchestration (MySQL Router, ProxySQL, Orchestrator) plutôt qu’un failover manuel

Prochaines étapes

Sauvegarde et restauration mysqldump, MySQL Shell, XtraBackup et PITR — complémentaire à la réplication

Monitoring et maintenance Performance Schema, slow queries, OPTIMIZE TABLE — surveiller la réplication

Sécuriser MySQL TLS entre source et replica, rôles dédiés et audit

Configurer MySQL Binary log, InnoDB buffer pool et les paramètres impactant la réplication

×

📖 Voir la documentation →