La réplication d’un base de données permet de disposer du même jeu de données à tout moment sur deux serveurs ou plus. MySQL permet d’automatiser la recopie des données entre une machine principale et plusieurs secondaires de façon unidirectionnelle (réplication master-slave) ou de façon bidirectionnelle entre 2 serveurs (réplication master-master). Dans ce tutoriel, nous allons mettre en place ces deux types de systèmes, le second étant une extension du premier.
Si vous n’avez pas lu mon article à propos de la création d’une architecture serveurs distribuée, je vous invite à le faire, et spécialement mon exemple de mise en en oeuvre avec 2 serveurs, vous comprendrez peut-être mieux l’utilité d’une configuration de ce type. Pour les plus pressées, sachez simplement que je proposais de créer 2 serveurs web accueillant chacun sa propre base de données, les données étant strictement identiques et chaque insertion ou modification de données étant immédiatement recopiée.
Plantons le décor : la configuration
Pour mettre en place ce système je vais utiliser deux serveurs MySQL 5.5.34 situés sur le même réseau local avec les adresses IP 192.168.10.10 (nous appellerons cette machine “rouge”) et 192.168.10.20 (nous l’appellerons “bleu”).
Sur ces 2 serveurs nous utiliserons un utilisateur appelé “replication_user”, dont le mot de passe sera “motdepasse”. Cet utilisateur aura bien entendu les privilèges nécessaires sur les bases de données que nous allons répliquer (dans cet exemple je prendrai toutes les bdd sans distinction).
Les manipulations ci-dessous sont aussi valables pour toutes les versions de MySQL supérieures ou égales à 5.5 sans adaptations et pour les versions précédentes avec quelques modifications que nous verrons en temps utile.
A priori le système d’exploitation des serveurs n’a aucune importance, vous pouvez même utiliser 2 machines ayant des OS différents.
Mettre en place une réplication MySQL master-slave
Procédons par étape et commençons par mettre en place une réplication maître-esclave, donc unidirectionnelle, du serveur “rouge” vers le serveur “bleu”.
En premier lieu nous allons paramétrer “rouge” pour autoriser notre utilisateur à répliquer les données. Pour cela, connectez-vous à la console MySQL et utilisez la commande suivante :
Eh oui c’est tout. Exportons maintenant les données pour les injecter sur “bleu” par la suite. Toujours dans la console, nous allons vider les caches des privilèges et des tables, tout en les verrouillant en lecture seule, à l’aide de la commande FLUSH :
Il ne vous reste plus qu’à faire un dump de vos bases de données pour l’injecter sur “bleu” par la suite, et à noter l’index du log binaire qui servira pour la réplication (les deux serveurs doivent avoir le même index en permanence). En utilisant la commande
Vous obtiendrez un tableau qui ressemble à cela :
Notez bien la valeur qui se trouve dans la colonne “position” (ici c’est 123456).
Passons maintenant à “bleu” qui va agir comme esclave de la réplication. Commencez par injecter le dump que vous venez de créer, puis allez sur la console MySQL du serveur pour taper les commandes suivantes :
Que signifie ces lignes ? Premièrement nous arrêtons la réplication, ensuite nous plaçons le serveur en tant que slave pour recopier sur “bleu” les données de “rouge” (vous pouvez identifier dans la 2° ligne l’adresse IP de “rouge”, le login et le mot de passe de l’utilisateur de réplication et l’index du log binaire que nous avons noté juste avant), enfin nous réactivons la réplication.
Revenons à “rouge” pour déverrouiller les tables :
Il ne vous reste plus qu’à redémarrer MySQL sur les deux serveurs et tout devrait fonctionner.
Paramétrer le slave pour MySql < 5.5
Je vous avais prévenu d’une petite adaptation pour les versions plus anciennes de MySQL : le paramétrage de l’esclave va se faire via le fichier my.cnf et pas dans la console MySQL. Ainsi, localisez ce fichier et éditez-le pour que la section [mysqld] comporte ces lignes :
[mysqld] server-id=20 master-host = 192.168.10.10 master-user = replication_user master-password = motdepasse master-port = 3306
Profitez-en aussi pour définir un server-id (par exemple 10) dans le fichier my.cnf du serveur maître.
Redémarrez bien les deux serveurs puisque le fichier my.cnf n’est lu qu’au démarrage du service.
Vérifier que la réplication fonctionne
Le moyen le plus simple de vérifier que tout fonctionne est le test : insérez une donnée sur le master (“rouge”) et vérifiez qu’elle est bien apparue sur le slave (“bleu”). A ce stade de notre tutoriel la réplication ne fonctionne que dans ce sens.
Pour en savoir un peu plus ou si ça ne fonctionne pas, vous devrez afficher les statuts des deux serveurs avec la commande
sur “rouge”, que nous avons déjà vue plus haut et la commande opposée :
sur “bleu” qui doit nous donner un tableau ressemblant à celui-ci
Le plus important est la première colonne : le serveur attend une commande du maître, viennent ensuite les informations concernant la réplication. Dans ce tableau vous trouverez aussi les informations sur la dernière erreur générée sur le slave par une requête de réplication (il s’agit des colonnes Last_SQL_Errno et Last_SQL_Error).
Mettre en place la réplication MySQL master-master
Vous avez bien compris qu’une réplication master-slave sert à recopier les données du maître vers l’esclave dans un seul sens. Pour rendre cette recopie bidirectionnelle, il suffit simplement de créer 2 réplications unidirectionnelles ! Ainsi nous allons maintenant appliquer les opérations faites sur “rouge” à “bleu” et celle faite sur “bleu” à “rouge”, bien entendu sans faire manipuler les données puisqu’elles sont déjà répliquées.
Commençons par promouvoir “bleu” en tant que master et récupérons son index :
Puis notons son index et donnons le rôle d’esclave à “rouge” :
Redémarrons les deux services et testons : inscrivez une donnée sur “rouge”, elle doit apparaître sur “bleu”. Effacez la de “bleu” et vérifiez qu’elle disparaît de “rouge”. Si cela fonctionne, vous avez réussi.
Moins contraignante que la mise en place d’un cluster, la réplication MySQL master-master est cependant limitée à deux serveurs (tandis que la réplication master-slave peut concerner un grand nombre d’esclaves). Elle est pleinement justifiée dans le cadre de la mise en place d’une architecture distribuée avec load balancing mais possède néanmoins quelques limites et peut s’avérer désastreuse en cas de désynchronisation des serveurs (rassurez-vous, il est toujours possible de resynchroniser les bases données).
Avez-vous déjà expérimenté ce type de configuration ? Quel est votre retour d’expérience ? Les commentaires sont à vous !