TP REPLICATION BASE DE DONNEES MySQL

Par
Edouard SARR
Enseignant-chercheur à UCAO-Saint Michel
edouard.sarr@ucao.edu.sn

REPLICATION ASYMETRIQUE SYNCHRONE

Présentation :
Il est important, dans une optique de sécurité et de disponibilité de l’information, d’avoir un processus à la fois
de réplication des informations en temps réel mais aussi de tolérance de panne. Plus précisément, si un serveur
dit « Master » tombe, un autre serveur « Slave » doit prendre le relais de manière immédiate et doit aussi avoir la
dernière version des informations.

Fonctionnement :
On part du principe que le serveur MySQL « Master » et le serveur MySQL « Slave » démarrent avec exactement
la même base de données qui seront identiques. Quand une réplication est active et que le
serveur MySQL « Master » connait son rôle, il va écrire toutes les requêtes modifiant son contenu (« UPDATE« ,
« DELETE« , « INSERT INTO« , …) dans un fichier tiers binaire qu’il aura créé lors de son démarrage, dans un
second temps il enverra à son où ses « Slave » un événement de réplication que le « Slave » stockera dans son
fichier binaire appelé « mysql-relay-bin« . De son coté, le serveur MySQL « Slave » qui aura dans ses paramètres
l’adresse, le port, les identifiants ainsi que des informations sur le fichier binaire en question ira lire ce fichier en
local et effectuera en temps réel les mêmes commandes sur sa propre base de données. Il est important de savoir
que l’on peut choisir de synchroniser une, plusieurs ou toutes les bases de données d’un serveur MySQL. Le nom
de ces bases doit être mis dans la configuration. Il est aussi à savoir que les processus d’écritures ne doivent se
faire uniquement sur le serveur MySQL Master. Si l’on commence à écrire sur le « Slave » et que le « Master »
ne contient pas cette modification, la synchronisation et la réplication seront faussées.

Mise en Œuvre
Notre serveur MySQL « Master » aura l’IP 192.168.0.1 et notre serveur MySQL « Slave » aura l’IP 192.168.0.2.
Les écritures depuis les serveurs web ou toute autres applications se feront donc directement sur le « Master » et
jamais sur le « Slave » (hormis si le « Master » est défaillant). Nous allons sur nos deux serveurs installer MySQL;

- Sur le master
On commence par la partie Maître, c’est-à-dire le serveur de prod numéro 1. On modifie le fichier de
configuration mysql/my.cnf de la manière suivante (on veillera à relancer le service mysql) :

[mysqld]
bind-address = IP serveur maître
server-id = 1
log_bin = mysql/log/mysql-bin.log
# Dans mon cas, c'est la ligne suivante qui spécifie quelle base répliquer
binlog_do_db = databaseName
Faut créer le fichier mysql/log/mysql-bin.log
Une fois ceci fait on crée un utilisateur « replicateur » pour le deuxième serveur (l’esclave) :

GRANT REPLICATION SLAVE ON *.* TO replicateur@'%' IDENTIFIED BY 'replicateur';

On va devoir s’assurer qu’aucune nouvelle donnée ne soit enregistrée pendant un petit laps de temps. Cette partie
est critique puisque il s’agit de bloquer l’écriture sur la base que l’on souhaite répliquer.
FLUSH TABLES WITH READ LOCK;
Il nous faut deux informations que l’on retrouve avec la commande ci-après : la position et le nom du fichier
binaire.

SHOW MASTER STATUS;

Pour finir, on fait un dump de la base (mysqldump) et on l’envoie sur le serveur esclave(scp). C’est tout pour le
serveur maître, on y reviendra à la fin pour le déverrouiller en écriture.
mysqldump -u root -p --database test1 > test1.sql
- Sur le client
Au niveau du second serveur, les manip’ sont semblables. On commence par modifier le fichier de
conf /etc/mysql/my.cnf puis on redémarre le service mysql.

[mysqld]
server-id =2
master-host = IP serveur maître
master-user = replicateur
master-password = replicateur
master-port = 3306
# Je rappelle ici la base à répliquer
replicate-do-db = databaseName
On va ensuite se servir des deux infos relevées plus haut en exécutant la commande :

CHANGE MASTER TO
MASTER_LOG_FILE='FILENAME',
MASTER_LOG_POS=POSITION;

Puis on démarre le process maître/esclave depuis l’esclave :

START SLAVE;
Soit ça marche, soit ça ne marche pas… Par exemple, pour 1 warning détecté, on devra reprendre les paramètres
de conf dans une requête de la forme :

CHANGE MASTER TO
MASTER_HOST=IP serveur maître,
MASTER_USER=replicateur,
....;
A partir de là, la réplication est prête. Seulement il faut effectuer le rattrapage sur le serveuresclave. La réplication
est démarrée mais notre deuxième serveur n’est qu’un esclave qui ne peut recréer la base et se mettre à niveau
du maître. C’est le maître qui donne les ordres donc comme on vient de commencer notre process maître/esclave,
le maître ne sait pas que la base de l’esclave est vide.
# On importe la base de données dans notre service MySQL
mysql -u root -p < test1.sql

Voilà pour la petite histoire et pourquoi un dump était utile. Il suffit maintenant d’insérer le dump transféré au
début. On retourne sur le serveur maître et on enlève le verrou d’écriture :

UNLOCK TABLES;
La réplication est en place. On peut tester l’ajout d’une ligne dans une table pour voir si la réplication fonctionne
parfaitement. Dorénavant, tout changement de la base maître (structures, données) sera répercuté sur la base
esclave.

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 « le master » à « Slave » et
celle faite sur « Slave » à « Master », bien entendu sans faire manipuler les données puisqu’elles sont déjà
répliquées.