Configuration de la réplication MySQL asynchrone : un guide étape par étape

Configuration de la réplication asynchrone MySQL : Un guide étape par étape

La réplication MySQL est une fonctionnalité fondamentale pour atteindre une haute disponibilité, une évolutivité et des stratégies de sauvegarde robustes. La réplication asynchrone, le type le plus courant, garantit que les données écrites sur le serveur primaire (Maître) sont éventuellement copiées sur un ou plusieurs serveurs secondaires (Esclaves), sans que le Maître n'attende la confirmation de la transaction par l'Esclave.

Ce guide complet fournit un tutoriel détaillé, étape par étape, pour configurer une réplication asynchrone Maître-Esclave standard à l'aide de MySQL. Nous couvrirons les ajustements nécessaires de la configuration du serveur, la configuration des utilisateurs et les étapes critiques pour initialiser la synchronisation des données.

Prérequis et Aperçu

Avant de commencer la configuration, assurez-vous d'avoir :

Deux serveurs MySQL en fonctionnement (Serveur A : Maître, Serveur B : Esclave).
Une connectivité réseau entre les deux serveurs (le port TCP 3306 doit généralement être ouvert).
Un accès root ou administratif pour configurer les deux instances MySQL et modifier les fichiers de configuration my.cnf ou my.ini.

Aux fins de ce guide, nous supposons que l'adresse IP du serveur Maître est 192.168.1.100 et celle du serveur Esclave est 192.168.1.101.

Phase 1 : Configuration du serveur Maître

Le serveur Maître doit être configuré pour enregistrer tous les événements de modification de données dans un fichier de journal binaire, à partir duquel l'Esclave lira.

Étape 1 : Modifier le fichier de configuration du Maître (`my.cnf`)

Localisez le fichier de configuration MySQL (généralement /etc/mysql/my.cnf ou /etc/my.cnf) et ajoutez ou modifiez les directives suivantes dans la section [mysqld].

[mysqld]
# 1. ID unique pour ce serveur (doit être supérieur à 0)
server-id=1

# 2. Activer la journalisation binaire
log-bin=mysql-bin

# 3. Liste des bases de données à répliquer (facultatif, mais recommandé)
# binlog-do-db=mydatabase

# 4. Facultatif : Assurer que la connexion utilise TCP/IP, utile pour les tests
# bind-address=0.0.0.0

Remarque : Le server-id doit être unique sur tous les serveurs participant à la topologie de réplication.

Étape 2 : Redémarrer MySQL et vérifier la journalisation binaire

Après avoir enregistré le fichier de configuration, redémarrez le service MySQL sur le serveur Maître.

# Debian/Ubuntu
sudo systemctl restart mysql
# RHEL/CentOS
sudo systemctl restart mysqld

Connectez-vous à l'interface de ligne de commande MySQL et vérifiez que la journalisation binaire est active :

SHOW VARIABLES LIKE 'log_bin';
-- La valeur devrait être ON

Étape 3 : Créer l'utilisateur de réplication

La réplication nécessite un compte utilisateur dédié sur le serveur Maître avec des privilèges spécifiques que l'Esclave utilisera pour se connecter et récupérer les journaux binaires. Assurez-vous que cet utilisateur peut se connecter à distance depuis l'adresse IP de l'Esclave (192.168.1.101).

CREATE USER 'repl_user'@'192.168.1.101' IDENTIFIED BY 'secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.101';
FLUSH PRIVILEGES;

Étape 4 : Enregistrer l'état actuel du Maître

Avant de continuer, nous devons établir la position exacte (Fichier et Position) dans le journal binaire où l'Esclave doit commencer à lire. Cette étape est critique pour la synchronisation.

FLUSH TABLES WITH READ LOCK; -- Arrêter temporairement les écritures
SHOW MASTER STATUS;

-- IMPORTANT : Notez ces deux valeurs :
-- Fichier : mysql-bin.000001
-- Position : 1234

-- NE DÉVERROUILLEZ PAS ENCORE LES TABLES SI VOUS EFFECTUEZ UNE PRISE DE VUE INITIALE (Étape 6)

Phase 2 : Configuration du serveur Esclave

Étape 5 : Modifier le fichier de configuration de l'Esclave (`my.cnf`)

Configurez le serveur Esclave avec un ID unique et des paramètres facultatifs.

[mysqld]
# ID unique pour ce serveur (doit être différent de celui du Maître)
server-id=2

# Facultatif : Recommandé pour la sécurité
read_only=1

# Facultatif : Activer la journalisation de relais
relay_log=mysql-relay-bin

Redémarrez le service MySQL sur le serveur Esclave après avoir enregistré les modifications.

Étape 6 : Transfert initial des données (Instantanné)

Si le serveur Esclave est vide, vous devez le peupler avec la structure de données et le contenu actuels du Maître. Cet instantané initial doit être pris tant que les tables du Maître sont verrouillées (depuis l'Étape 4).

Depuis le serveur Maître, exécutez la commande mysqldump. Nous utilisons le drapeau --master-data=2 pour inclure automatiquement l'instruction CHANGE MASTER TO nécessaire dans le fichier de dump, ce qui simplifie l'Étape 7.

# Exécuter sur la console/shell du serveur Maître
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > master_dump.sql

# Maintenant, revenez à l'interface de ligne de commande MySQL du Maître et libérez le verrou
UNLOCK TABLES;

Transférez master_dump.sql vers le serveur Esclave et importez-le :

# Exécuter sur la console/shell du serveur Esclave
mysql -u root -p < master_dump.sql

Bonne pratique : L'utilisation de master-data=2 est fortement recommandée car elle automatise la capture de la position correcte du journal binaire dès le début du dump.

Phase 3 : Démarrage de la réplication

Étape 7 : Définir la connexion Maître

Sur la ligne de commande MySQL du serveur Esclave, exécutez la commande CHANGE MASTER TO, en substituant les valeurs notées à l'Étape 4 et l'utilisateur créé à l'Étape 3.

CHANGE MASTER TO
    MASTER_HOST='192.168.1.100',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='secure_password',
    MASTER_LOG_FILE='mysql-bin.000001', -- Le Fichier enregistré à l'Étape 4
    MASTER_LOG_POS=1234;              -- La Position enregistrée à l'Étape 4

Étape 8 : Démarrer la réplication et la vérification

Après avoir défini les paramètres de connexion, démarrez les threads de réplication de l'Esclave.

START SLAVE;

Vérifiez que les threads de réplication fonctionnent et communiquent correctement en utilisant la commande SHOW SLAVE STATUS :

SHOW SLAVE STATUS\G

Examinez la sortie pour les champs critiques suivants :

Champ	Valeur attendue	Description
`Slave_IO_Running`	`Yes`	L'Esclave se connecte avec succès au Maître.
`Slave_SQL_Running`	`Yes`	L'Esclave applique les transactions à sa base de données.
`Seconds_Behind_Master`	`0` ou un nombre faible	Indique la latence de réplication. Devrait rapidement tomber à 0.

Si Slave_IO_Running ou Slave_SQL_Running affiche No, examinez les champs Last_IO_Error ou Last_SQL_Error pour des indices de dépannage (par exemple, problèmes de pare-feu, identifiants incorrects, clés en double).

Conseils de dépannage et de maintenance

Gestion des erreurs de réplication

Si l'Esclave rencontre une erreur (par exemple, une tentative d'insertion d'une clé primaire en double), le thread Slave_SQL_Running s'arrêtera. Vous pouvez généralement contourner les erreurs mineures et non critiques en utilisant :

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

Avertissement : Utilisez SQL_SLAVE_SKIP_COUNTER avec discernement. Le fait de sauter des transactions peut entraîner une divergence de données (incohérence) entre le Maître et l'Esclave.

Vérification de la cohérence

Bien que la réplication asynchrone soit efficace, elle ne garantit pas une cohérence immédiate. Pour les environnements à enjeux élevés, utilisez des outils comme pt-table-checksum de Percona Toolkit pour vérifier périodiquement la dérive des données entre le Maître et l'Esclave.

Gestion des journaux binaires

Les journaux binaires consomment de l'espace disque avec le temps. Configurez l'expiration des journaux sur le Maître pour éviter la surutilisation du disque :

[mysqld]
# Supprimer les journaux binaires plus anciens que 7 jours (604800 secondes)
expire_logs_days=7