Ce petit article est un mémo pour faire une réplication Master-Slave.
Le principe est très simple, le Master enregistre toutes les modifications dans un fichier de logs (log binaire), les Slaves vérifient l’état de ces fichiers et appliquent les modifications.
Il ne faut bien évidemment pas écrire directement dans les bases répliquées sur les Slaves.
On va partir sur une architecture simple composée d’un serveur maitre et de 2 serveurs esclaves, avec une base en réplication (mabase).
Master : 192.168.0.101 Slave 1 : 192.168.0.201 Slave 2 : 192.168.0.202
Configuration du master
Dans la section [mysqld]
Le Master doit pouvoir être contacté par les Slaves :
bind-address = 192.168.0.101
On peut également mettre la ligne en commentaire, ce qui équivaut à 0.0.0.0.
Les logs binaires doivent être activés (ici on les active pour toutes les bases, mais ce n’est pas obligatoire) :
#l'ID du serveur doit être unique sur l'ensemble des serveurs impliqués #dans la réplication server-id = 1 #Emplacement des logs binaires, s'il y a beaucoup de mouvements dans la base #il faut prévoir un emplacement avec suffisamment d'espace log_bin = /var/log/mysql/mysql-bin.log #Durée de vie des anciens logs binaires #pour supprimer les anciens logs, utilisez : mysqladmin -uroot -p flush-logs expire_logs_days = 7 #Taille maximale d'un log binaire avant rotation max_binlog_size = 256M
On relance le serveur :
service mysql restart
La réplication ne prenant en compte que les modifications, il faut faire un dump de la base source à un instant T, pour plus de sécurité, on verrouille les tables (attention, selon le moteur des tables, les options de verrouillage peuvent changer).
On se connecte à la base maitre :
USE mabase; FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;
+------------------+----------+---------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+---------------+------------------+ | mysql-bin.000004 | 169 | mabase | | +------------------+----------+---------------+------------------+
Il faut bien noter les informations de fichier courant (File) et de position (Position).
On fait le dump :
mysqldump -u root -p --add-drop-database --master-data=2 --databases mabase > mabase.sql
Le paramètre –master-data=2 permet d’ajouter les informations de fichier courant et de position en commentaire dans le dump.
On peut alors enlever le verrou, on en profite pour créer l’utilisateur qui sera utilisé pour la réplication :
USE mabase; UNLOCK TABLES; GRANT REPLICATION SLAVE ON *.* TO 'copieur'@'%' IDENTIFIED BY 'password';
En production, il faudrait être plus restrictif au niveau des droits.
S’en est fini des opérations sur le maitre. Toutes les modifications depuis le redémarrage sont enregistrées dans les logs binaires.
Esclaves :
Les 2 serveurs esclaves ont la même configuration dans cet exemple, mais on peut aussi répliquer une partie des bases sur l’un et une partie sur l’autre.
On arrête les 2 serveurs et on modifie la section [mysqld] comme suit :
#201 pour le premier esclave, 202 pour le second server-id=201 master-user=copieur master-password=password master-connect-retry=60 replicate-wild-do-table = mabase.%
On peut relancer les 2 serveurs.
Il faut maintenant restaurer le dump (que l’on aura transféré au préalable) sur les esclaves :
mysql -u root -p mabase < mabase.sql
Puis on se connecte pour mettre en marche la réplication :
SLAVE STOP; CHANGE MASTER TO MASTER_HOST='192.168.0.101', MASTER_USER='copieur', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=169; START SLAVE;
Si tout s’est bien déroulé, vos esclaves sont entrain de se synchroniser avec le serveur maitre.
sources : MySQL Plus d’informations sur : www.networklife.net