The ZATAZ network :: ZATAZ.com :: ZATAZ.net


Documentation : Réplication MySQL

Date de publication : 13.7.2004
Date de modification : 2.3.2007

Contributeur : Eric Romang

Société : ZATAZ / http://www.zataz.net

Eric Romang co-fondateur de ZATAZ, avec Damien Bancal, supervise la direction technique de ZATAZ.

Situé au Luxembourg, Eric Romang a eu l'occasion au cours de ses années d'expériences dans le domaine au sein de datacenter de développer une expertise dans la haute disponibilité d'infrastructure, la mise en place de cluster MySQL, de solutions de stockages, de sauvegardes et de sécurisation d'environnement Linux.


Sommaire

Introduction

La réplication MySQL est apparue avec la version 3.23.15 de MySQL et est à sens unique, c'est-à-dire que vous ne pouvez répliquer les données que dans un sens (La réplication bi-directionnelle est aussi envisageable pour des tables ne contenant pas de clés primaires, d'index, et de champ auto-incrémentable).

Le premier serveur joue le rôle de maître et tous les autres serveurs jouent le rôle d'esclave. Le serveur maître garde un fichier log, au format binaire, des mises à jour effectuées et un fichier de référence pour la rotation des logs. Le serveur esclave quand à lui informe tout d'abord le maître de la dernière fois qu'il est venu effectuer la réplication, et à partir de cette information regarde si de nouvelle donnée sont apparues.

ATTENTION : Toute les modifications sont effectuées sur le serveur maître, si une modification est effectuée sur un serveur esclave, la réplication se brise. Il vous faudra alors rétablir la réplication entre les serveurs.

La réplication unidirectionnelle de bases de données à plusieurs avantages :

# Fournie une sécurité au niveau de l’intégrité des données stockées (si la base de donnée maître est indisponible, il vous suffit de basculer sur la base de donnée esclave qui contient une réplique exacte des données du serveur maître).

# Répartition de la charge possible afin d’augmenter la disponibilité des services. Les requêtes SELECT peuvent être effectuée sur les serveurs esclaves pour reduire la charge du serveur maître. Les requêtes de modifications sont envoyées au serveur maître qui les transmettra aux serveurs esclaves.

# Sauvegarde non-bloquantes des données, en effectuant celle-ci non plus sur le serveur maître, mais sur le ou les serveurs esclaves.

Les logs binaires

Les logs binaires doivent remplacer le format de log classique de MySQL, et ces mêmes logs permettent d'effectuer des replications MySQL.

Lorsqu'on démarre MySQL avec l'option --log-bin[=nom du fichier], MySQL écrit un fichier log qui contient toutes les requêtes SQL qui ont permis de mettre à jour vos bases de données. Si aucun nom de fichier n'est donné, le fichier log commencera un -bin et le nom de la machine. Si un nom de fichier est donné, mais qu'il ne contient pas de chemin d'accès, ce fichier sera alors stocké dans le répertorie DATA ou VAR de MySQL. Si vous rajouter un extension au fichier du type --log-bin=fichier.extension, l'extension sera supprimée automatiquement.

Vous pouvez aussi n'enregistrer les logs binaires que pour une seule base de données avec l'option de démarrage MySQL --binlog-do-db=base. Ou encore vous pouvez exclure une base de donnée de la réplication MySQL avec l'option de démarrage --binlog-ignore-db=base

Implémentation

La réplication MySQL est basé sur le fichier log binaire du serveur maître, étudié ci-dessus, qui garde une trace de toutes les requêtes SQL (update, delete, etc.). Le serveur esclave quand à lui va lire le fichier log binaire du serveur maître pour qu'il puisse exécuter les requêtes SQL stockées dans ce fichier.

Si vous désirez mettre une réplication en place, alors que la base de donnée, concernée par la réplication, du maître est déjà fournies en donnée, il vous faut tout d'abord effectuer une copie complète de celle-ci avant de commencer une réplication. La réplication ne va pas reconstituer intégralement votre base, mais uniquement commencé à l'instant ou vous l'avez initiée.

Une façon de copier les données du serveur maître vers le serveur esclave est d’utiliser la commande LOAD DATA FROM MASTER disponible à partir de la version 4.0.0 et qui ne fonctionne qu’avec des tables du type MyISAM. Lors de l’exécution de cette commande les bases de données du serveur maître ont un état READ LOCK, ce qui veut dire qu’aucune mise à jour sur le serveur maître n’est possible lors du transfert des tables vers le serveur esclave.Dans le version MySQL 5.0 en cours de développement l’état READ LOCK ne sera plus nécessaire.

Du à ces limitations, nous vous recommandons de n’utiliser la commande LOAD DATA FROM MASTER seulement si la quantitée de données est relativement faible, ou si un état READ LOCK prolongé sur le serveur maître est acceptable. La vitesse d’exécution de la commande LOAD DATA FROM MASTER varie d’un système à l’autre, une moyenne de vitesse de transfert est d’environ de 1MB de données transférées par seconde (basé sur des calculs avec un Pentium 700 Mhz et une connection réseau de 100Mbit/s).

Après que le serveur esclave ai récupéré une copie des données du serveur maître, le serveur esclave se connectera sur le serveur maître uniquement pour récupérer les processus de mise à jour. Si le serveur esclave n’est plus disponible, ou que le serveur esclave perd la connexion avec le serveur maître, celui-ci va continuer périodiquement d’essayer de se reconnecter tant qu’il ne pourra pas contacter le serveur maître et mettre à jour la réplication. L’interval de reconnexion est controler par l’option –master-connect-retry dont la valeur par défault est 60 secondes.

Chaque serveur esclave garde une trace de l’interruption de la connexion. Le serveur maître n’a pas de trace du nombre de serveur esclave configuré et s’ils sont à jour ou pas.

Les étapes suivantes sont nécessaires à réaliser pour toutes mise en place de réplication :

# Vérifier que vous avez bien mis en place un serveur maître et esclave avec une version supérieure à 3.23.29, les version antérieures n'ont pas le même format de fichier log

# Ajouter un utilisateur MySQL spécifique à la réplication sur le serveur maître, avec comme droits FILE et la permissions de se connecter de tous les serveurs esclaves.

Pour les versions antérieures à la version 4.0

mysql> GRANT FILE ON *.* TO repli@serveur-esclave IDENTIFIED BY '';

Pour les versions supérieures à la version 4.1

mysql> REPLICATION SLAVE ON *.* TO repli@serveur-esclave IDENTIFIED BY '';

# Si vous ne possédez que des tables du type MyISAM, vous avez la possibilité d'exécuter le commande suivante :

mysql> FLUSH TABLES WITH READ LOCK;

Cette commande permet d'éviter que des écritures soient effectuées lors de la création de l'image de votre base de donnée que vous voulez répliquer.

Si vous ne possédez pas que des tables MyISAM, vous pouvez alors utiliser la commande mysqldump --master-data.

Faîtes une copie intégrale des tous les DATA de votre serveur maître. La façon la plus simple est de faire un TAR de tous le répertoire DATA ou VAR. Si vous avez utilisé la commande mysqldump --master-data vous n'avez pas besoin d'effectuer un TAR de vos tables ou bases.

# Toujours sur le serveur maître, créer ou éditer le fichier /etc/mysql/my.cnf et ajouter les lignes suivantes :

[mysqld]
log-bin
server-id = 1

# Si vous avez exécuter la commande :

mysql> FLUSH TABLES WITH READ LOCK

vous pouvez maintenant lancer la commande pour autoriser les écritures dans la base de donnée du serveur maître par la commande SQL suivante :

mysql> UNLOCK TABLES;

# Editer ou créer le fichier /etc/mysql/my.cnf sur le (ou les) serveur esclave et ajouter les lignes suivantes :

master-host = 'nom d'hôte du serveur maître'
master-user = 'nom d'utilisateur de la réplication, ici repli'
master-password = 'mot de passe de l'utilisateur repli'
master-port = 'port de la connexion tcp/ip, 3306'
master-connect-retry = 'nombre de secondes'
master-info-file = '/var/lib/mysql/master.info'
server-id= '2 si vous n'avez qu'un seul serveur esclave, et en incrémentation pour les autres'

En complément de cette configuration my.cnf, vous pouvez aussi rajouter :

replicate-do-table = base.table, réplique une table de la base concernée.
max-relay-log-size = 50M , rotation automatique des logs binaires.
relay-log-space-limit = 150M , limite la taille disque des fichiers logs relay.
skip-slave-start, démarrage de la réplication uniquement par le biais de SLAVE START

# Décompressez l'archive TAR précédente pour remplacer le répertoire DATA du serveur esclave. Vérifier bien si les droits sont correctes.

#Démarrez le serveur esclave.

Vous pouvez tester votre réplication en insérant une table dans une de vos base et en y ajoutant une valeur quelconque. Sinon, les commandes suivantes vous permettent d'avoir des informations sur l'état de votre réplication :

mysql> SHOW MASTER STATUS

mysql> SHOW SLAVE STATUS

mysql> SHOW MASTER LOGS

Si la réplication ne s'effectue pas, vous pourrez trouver les erreurs dans le fichier error du serveur esclave. A partir du moment que le serveur esclave commence à répliquer, vous trouverez un fichier master.info au même endroits que le fichier d'erreur. Ce fichier permet d'effectuer un tracking des données déjà répliquées et à quels moments. Ne supprimer pas ce fichier.


contentRight


valider