Mise en place d'une réplication Mysql maître/esclave.
La
réplication Mysql consiste à avoir en temps réel deux bases de données
Mysql identiques sur deux serveurs différents afin de pouvoir basculer
si besoin sur le deuxième serveur en cas de défaillance du premier. Les
exemples ci-dessous traitent d'un magasin équipé de caisses mais on
peut les appliqués à n'importe quels autres environnements.
Interêts : La réplication, non seulement permet de
rendre une caisse autonome, donc de poursuivre la facturation client,
en cas de défaillance du serveur, mais elle permet aussi de rendre l'autonomie complète au magasin suite au crash du serveur.
Pré-requis :
Deux serveurs Mysql fonctionnels, un serveur maitre (nommé server) et une caisse esclave (nommée caisse1).
Faire les tests de connexion sous mysql avec les utilisateurs créés.
(serveur sur le serveur maitre et caisse1 sur la caisse esclave)
NB: Il faut que la connexion caisse ==> serveur soit opérationnelle avant d'aller plus loin.
Le serveur maitre :
On commence par faire une sauvegarde avec Laurux. Il s'agit d'un dump de la base de données Laurux qui génère un fichier nommé Laurux.sql.
On se connecte à la base de donnée du serveur maître.
mysql -h ipserver -u root -ppassword
ou
mysql -u root -p (en local)
On crée un utilisateur nommé replic qui sera utilisé pour la réplication :
GRANT REPLICATION SLAVE ON *.* TO replic@'%' IDENTIFIED BY 'replic';
On interdit l’écriture sur les bases :
FLUSH TABLES WITH READ LOCK;
Pour annulé l'interdit (mais ne le faites pas maintenant :p) :
UNLOCK TABLES;
Arrêtez le serveur maître :
service mysql stopou
invoke-rc mysql stop
Editez le fichier my.cnf qui se trouve normalement dans /etc/ mysql/:
Ajoutez-y les lignes suivantes :
[mysqld]log-bin
server-id=1
Vérifiez aussi la ligne bind-adress qui doit être 0.0.0.0
Relancez le serveur Mysql :
service mysql startou
invoke-rc mysql start
On récupère le nom du fichier binaire, et son offset. Notez les, nous en auront besoin après pour configurer l’esclave.
SHOW MASTER STATUS;
Noter le nom du fichier dans la colonne “File” qui doit ressembler normalement à log-bin-… et noter aussi le numéro dans "Position".
mysql > SHOW MASTER STATUS;
+---------------------+------------+---------------------+--------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+------------+---------------------+--------------------------+
| mysql-bin.003 | 73 | test,bar | foo,manual,mysql |
+---------------------+------------+---------------------+--------------------------+
1 row in set (0.06 sec)
Lever l'interdiction d'écriture sur le serveur
UNLOCK TABLES;
quit;
On configure maintenant le serveur esclave (ipcaisse1) :
On commence par faire une restauration avec Laurux de la sauvegarde effectuée sur le serveur au tout début de la procédure.
Éteignez le serveur comme vu plus haut (service mysql stop)
ou avec cette commande : mysqladmin -u root -ppassword -h ipcaisse1 -P 3306 shutdown
Éditez le fichier my.cnf du serveur secondaire et :
Ajoutez-y les lignes suivantes :
[mysqld]
server-id=2
master-host = ipserver
master-user = replic
master-password = replic
master-port = 3306
Vérifiez aussi la ligne bind-adress qui doit être 0.0.0.0
Relancez le serveur Mysql esclave comme vu plus haut pour le serveur maitre (service mysql start).
On se connecte au prompt Mysql :
mysql -u root -ppassword -h ipcaisse1 -P 3306
ou
mysql -u root -p
On change les données comme ceci :
NB: File et Position sont les données notées plus haut sur le server.
STOP SLAVE; On arrete l'esclave
CHANGE MASTER TO
MASTER_LOG_FILE = 'File', Bien mettre les apostrophes et la virgule
MASTER_LOG_POS = Position; Bien mettre le point-virgule
On démarre l’esclave
START SLAVE;
Si tout c’est déroulé correctement, vous devriez voir quelque chose comme ceci :
SHOW SLAVE STATUS;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: ServerA-bin.000001
Read_Master_Log_Pos: 98
Relay_Log_File: ServerB-relay-bin.000002
Relay_Log_Pos: 238
Relay_Master_Log_File: ServerA-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 238
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.00 sec)
Et avec la commande SHOW PROCESSLIST:
SHOW PROCESSLIST;
+----+-------------+----------------------------+------+---------+------+----------------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------------+----------------------------+------+---------+------+----------------------------------------------------------------------+------------------+
| 6 | system user | | NULL | Connect | 1944 | Waiting for master to send event | NULL |
| 7 | system user | | NULL | Connect | 1944 | Has read all relay log; waiting for the slave I/O thread to update it | NULL
| 8 | admin | serverB.lan:45148 | NULL | Query | 0 | NULL | SHOW PROCESSLIST |
+----+-------------+----------------------------+------+---------+------+----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)
En cas d’erreur de réplication, On vérifie l’état du serveur esclave :
mysql -u root -ppassword -h ipcaisse1 -P 3306
SHOW SLAVE STATUS ;
Il arrive que certaines requêtes réussissent sur le maître mais échouent sur l’esclave. Cela ne devrait pas arriver si vous avez pris la bonne sauvegarde du maître, et que vous n’avez jamais modifié les données sur le serveur esclave, autrement que par la réplication.
Si vous apercevez une erreur aux 2 lignes suivantes :
Last_Errno:
Last_Error:
Voici comment faire :
Sur le master :
mysql -u root -ppassword -h ipserver –P 3306
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Noter le nom du fichier dans la colonne “File” qui doit ressembler normalement à log-bin-… et notez également le numéro “Position”.
Faire un DUMP de la base de donnée:
mysqldump -u root -ppassword -r /root/dump.sql Laurux.sql
Envoyer le fichier dump du serveur maître vers le serveur esclave:
scp /root/dump.sql root@1ipcaisse1:/root
Sur le Slave, on bloque l'écriture :
mysql -u root -ppassword -h ipcaisse1 -P 3306
FLUSH TABLES WITH READ LOCK;
exit;
On intègre le dump du master dans la base “Laurux” :
mysql -h ipcaisse1 -u root -ppassword -P 3306 Laurux < /root/Laurux.sql
On définit le bon fichier binaire du master et on redémarre le Slave:
mysql -u admin -ppassword -h ipcaisse1 -P 3306
CHANGE MASTER TO
-> MASTER_LOG_FILE='',
-> MASTER_LOG_POS=POSITION_FICHIER_LOG;
START SLAVE;
Normalement, la réplication est repartie correctement.
En cas de crash du serveur maitre – Remise à niveau du master et de la réplication :
Première phase.
Si le serveur s'arrete, il faudra sur chaque poste, se connecter, avec Laurux, sur la base du serveur esclave.
Cela permettra de travailler dan l'attente de la réparation du serveur maitre.
Deuxième phase.
Le serveur maitre étant réparé, nous allons maintenant remettre la base MySQL et réactiver la réplication. A ce moment, le serveur esclave est LA base de référence. Donc nous allons commencer par stopper le serveur esclave, créer un DUMP du serveur esclave, le répliquer sur le serveur maitre, et relancer le tout.
SUR LE SERVEUR ESCLAVE:
On stop l’écriture sur la base:
mysql -u root -ppassword -h ipcaisse1 -P 3306
FLUSH TABLES WITH READ LOCK;
quit;
On fait une sauvegarde de la base avec Laurux:
SUR LE SERVEUR MAITRE:
On stop l’écriture sur la base:
mysql -h ipserver -u root -ppassword
ou
mysql -u root -p (en local)
FLUSH TABLES WITH READ LOCK;
quit;
On fait une restauration de la base avec Laurux:
On récupère le nom du fichier binaire, et son offset. Il faut bien les noter car nous en auront besoin après pour configurer l’esclave.
mysql -h ipserver -u root -ppassword
ou
mysql -u root -p (en local)
SHOW MASTER STATUS;
Noter le nom du fichier dans la colonne File qui doit ressembler normalement à log-bin-… et noter également le numéro Position.
Exemple:
SHOW MASTER STATUS;
+---------------------+------------+---------------------+--------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+------------+---------------------+--------------------------+
| mysql-bin.003 | 73 | test,bar | foo,manual,mysql |
+---------------------+------------+---------------------+--------------------------+
1 row in set (0.06 sec)
exit
SUR LE SERVEUR ESCLAVE:
Nous allons maintenant re-synchroniser le Serveur esclave avec le master.
On redéfinit le bon fichier binaire du master et on redémarre le Serveur esclave:
mysql -u root -ppassword -h ipcaisse1 -P 3306
CHANGE MASTER TO
MASTER_LOG_FILE='',
MASTER_LOG_POS=POSITION_FICHIER_LOG;
START SLAVE;
Normalement, la réplication est repartie !
Vous pouvez vérifier l'etat du serveur esclave, avec les commandes SLAVE STATUS, et SHOW PROCESSLIST.
Si vous désirez aller plus loin : http://dev.mysql.com/doc/refman/5.0/fr/replication.html
NB : Cette documentation a été faite à l'aide des nombreux exemples qu'on peut trouver sur internet.