MySQL Group Replication (MGR) est une solution de haute disponibilité et d'extensibilité native introduite par MySQL. Basée sur le protocole Paxos, elle garantit la cohérence des données et la tolérance aux pannes sans recourir à des outils tiers complexes. Contrairement à la réplication classique maître-esclave, MGR gère automatiquement l'élection du nœud primaire et la résolution des conflits d'écriture.

Prérequis et Limitations Architecturales

Avant de déployer MGR, il est impératif de respecter certaines contraintes techniques :

• Moteur de stockage : InnoDB est obligatoire pour la gestion des transactions et la détection des conflits.
• Clés primaires : Chaque table doit posséder une clé primaire explicite.
• Journalisation binaire : Le format ROW est requis.
• GTID : Les identifiants globaux de transaction doivent être activés.
• Isolation : Le niveau d'isolation SERIALIZABLE n'est pas supporté. Les verrous d'intervalle (gap locks) de REPEATABLE READ peuvent poser problème, il est souvent recommandé d'utiliser READ COMMITTED.
• Limites : Le cluster supporte un maximum de 9 nœuds. Les clés étrangères ne sont pas supportées en mode multi-primaire.

Note : Assurez-vous d'utiliser une version de MySQL 5.7.20 ou supérieure (ou MySQL 8.0), car le plugin group_replication.so est natif et stable à partir de ces versions.

Préparation de l'Environnement

Notre cluster seera composé de trois nœuds sous CentOS 7 avec MySQL 5.7.28 :

• node-db-01 : 10.0.0.11 (server-id=101)
• node-db-02 : 10.0.0.12 (server-id=102)
• node-db-03 : 10.0.0.13 (server-id=103)

Configurez la résolution DNS locale sur chaque serveur via /etc/hosts :

10.0.0.11 node-db-01
10.0.0.12 node-db-02
10.0.0.13 node-db-03

Ouvrez les ports nécessaires (MySQL et communication de groupe) dans le pare-feu :

firewall-cmd --permanent --add-port={3306,13306}/tcp
firewall-cmd --reload

Ajustez le port de communication (13306) pour les autres nœuds (13307, 13308).

Configuration du Mode Primaire Unique (Single-Primary)

1. Configuration du Fichier my.cnf

Appliquez la configuration suivante dans la section [mysqld] de chaque nœud. Adaptez le server-id et le loose-group_replication_local_address pour chaque machine.

[mysqld]
server-id=101
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
transaction_write_set_extraction=XXHASH64

# Paramètres MGR
loose-group_replication_group_name="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
loose-group_replication_start_on_boot=OFF
loose-group_replication_local_address="node-db-01:13306"
loose-group_replication_group_seeds="node-db-01:13306,node-db-02:13307,node-db-03:13308"
loose-group_replication_bootstrap_group=OFF

Redémarrez le service MySQL sur tous les nœuds après modification.

2. Initialisation du Nœud Primaire (node-db-01)

Créez l'utilisateur de réplication et configurez le canal de récupération :

CREATE USER 'sync_user'@'10.0.0.%' IDENTIFIED BY 'SecurePass!2023';
GRANT REPLICATION SLAVE ON *.* TO 'sync_user'@'10.0.0.%';
FLUSH PRIVILEGES;

CHANGE MASTER TO MASTER_USER='sync_user', MASTER_PASSWORD='SecurePass!2023' 
FOR CHANNEL 'group_replication_recovery';

Installez le plugin et démarrez le groupe en mode bootstrap :

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

Vérifiez l'état du cluster :

SELECT MEMBER_HOST, MEMBER_STATE FROM performance_schema.replication_group_members;

3. Ajout des Nœuds Secondaires (node-db-02 et node-db-03)

Sur les nœuds restants, exécutez les commandes de création d'utilisateur, de configuration du canal et d'installation du plugin comme sur le premier nœud. Ensuite, joignez le cluster sans bootstrap :

SET GLOBAL group_replication_allow_local_disjoint_gtids_join=ON;
START GROUP_REPLICATION;

4. Validation et Basculement (Failover)

En mode primaire unique, seul le nœud élu accepte les écritures. Vérifiez les variables read_only :

SHOW VARIABLES LIKE '%read_only%';

Le primaire aura read_only=OFF, tandis que les secondaires auront super_read_only=ON.

Si vous arrêtez le service MySQL sur node-db-01, le protocole Paxos élira automatiquement un nouveau primaire parmi les nœuds restants. Les écritures reprendront sans intervention manuelle.

Transition vers le Mode Multi-Primaire (Multi-Primary)

Le mode multi-primaire permet à tous les nœuds d'accepter des écritures simultanément. Pour basculer dynamiquement :

-- Arrêter la réplication sur tous les nœuds
STOP GROUP_REPLICATION;

-- Modifier le mode sur tous les nœuds
SET GLOBAL group_replication_single_primary_mode=OFF;
SET GLOBAL group_replication_enforce_update_everywhere_checks=ON;

-- Redémarrer le groupe sur un nœud (bootstrap)
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

-- Démarrer sur les autres nœuds
START GROUP_REPLICATION;

Assurez-vous également de mettre à jour le fichier my.cnf avec loose-group_replication_single_primary_mode=OFF pour persister ce changement après un redémarrage.

Gestion des Pannes et Réintégration

Lorsqu'un nœud tombe en panne, il est exclu du cluster. Une fois le service restauré, il suffit de relancer la réplication pour qu'il se resynchronise automatiquement via les GTID manquants :

START GROUP_REPLICATION;

Si le nœud a été hors ligne trop longtemps et que les journaux binaires ont été purgés, une restauration manuelle via un dump logique ou physique sera nécessaire avant de réintégrer le groupe.