| 6 Réplication de MySQL
 Manuel de Référence MySQL 4.1 : Version Française
 
 . Introduction à la réplication
 . Présentation de l'implémentation de la réplication
 . Détails d'implémentation de la réplication
 ->Comment mettre en place la réplication
 . Compatibilité de la réplication entre les versions de MySQL
 . Changer de version de réplication
 . Replication Features, Replication Options, Replication Upgrade, Replication
 . Options de démarrage de la réplication
 . FAQ de la réplication
 . Correction de problèmes courants
 . Rapporter des bugs de réplication
 
 
 | 
  6.4 Comment mettre en place la réplication 
Voici les instructions pour mettre en place la réplication sur votre
serveur MySQL. Nous supposons que vous voulez répliquer toutes vos bases, et que
vous ne l'avez jamais configuré auparavant. Vous aurez besoin d'éteindre 
brièvement le serveur principal pour suivre toutes les instructions.
 
 
La procédure est écrite pour configurer un esclave seul, mais elle peut être
répétée pour configurer plusieurs esclaves.
Si cette méthode n'est pas la plus simple pour configurer un esclave,
ce n'est pas la seule. Par exemple, si vous avez déjà une sauvegarde des
données du maître, et que le maître a déjà un identifiant de serveur,
et le log binaire activé, vous pouvez configurer l'esclave sans éteindre
le serveur et sans bloquer les mises à jours. Pour plus de détails, voyez
 FAQ de la réplication . 
Si vous voulez administrer une architecture de réplication MySQL, nous vous
suggérons de commencer par étudier, tester et expérimenter toutes les commandes
mentionnées dans les chapitres  Commandes SQL pour contrôler les maîtres  et  Commandes SQL pour contrôler les esclaves . 
Vous devriez aussi vous familiariser
avec les options de démarrage décrites dans la section  Options de réplication .
 
Assurez vous que vous avez une version récente de MySQL installée comme 
maître et comme esclave. Assurez vous que ces versions sont compatibles entre
elles, conformément à la table présentée dans la section  Mettre à jour une architecture de réplication .
 
Ne nous rapportez pas de bugs tant que vous n'avez pas vérifié que le problème
persiste dans la dernière version de MySQL.
Créez un utilisateur MySQL spécial pour la réplication sur le maître, avec
les droits de  
FILE
  (dans les versions plus anciennes que la 
versions 4.0.2) ou le droit de  
REPLICATION SLAVE
  pour les nouvelles
versions. Vous devez aussi lui donner les droits de connexion depuis tous les
esclaves. Si l'utilisateur ne fait que de la réplication (ce qui est recommandé),
vous n'avez pas à lui donner d'autres droits.
 
Le nom d'hôte du compte doit être tel que chaque serveur esclave peut l'utiliser
pour se connecter au maître.
Par exemple, pour créer un utilisateur appelé  
repl
  qui peut accéder au maître,
vous pourriez utiliser une commande comme :
 Pour les versions de MySQL antérieure à la 4.0.2, utilisez cette commande :| 
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY '<password>';
 | 
 Si vous envisagez d'utiliser  
LOAD TABLE FROM MASTER
  ou 
 
LOAD DATA FROM MASTER
  sur l'esclave, vous devez donner les droits
supplémentaires suivants :| 
mysql> GRANT FILE ON *.* TO repl@'%' IDENTIFIED BY '<password>';
 | 
 
Donnez le droit de  
SUPER
  et  
RELOAD
 .
Donnez le droit de  
SELECT
  pour toutes les tables que vous voulez
charger. Toutes les tables maîtres dans lesquelles l'esclave ne 
pourra pas utiliser  
SELECT
  seront ignorées par  
LOAD DATA FROM MASTER
 .
Si vous utiliez des tables MyISAM, déchargez toutes les tables et blocs
en utilisant la commande  
FLUSH TABLES WITH READ LOCK
 . 
puis faire une sauvegarde des données de votre maître.Le plus simple pour cela (sous Unix) et d'utiliser la commande  
tar
 
pour produire une archive de votre dossier de données total. Le dossier
de données dépend de votre installation.| 
mysql> FLUSH TABLES WITH READ LOCK;
 | 
 Si vous voulez que vos archives incluent seulement une base de données
appelée  
cette_base
 , utilisez cette commande :| 
shell> tar -cvf /tmp/mysql-snapshot.tar .
 | 
 Puis copiez le fichier d'archive dans le dossier  
/tmp
  sur le serveur
esclave. Sur cette machine, placez vous dans le dossier de données du serveur
et décompressez l'archive locale avvec cette commande :| 
shell> tar -cvf /tmp/mysql-snapshot.tar ./cette_base
 | 
 Il n'est pas besoin de répliquer la base  
mysql
 . Si c'est le cas, vous pouvez
l'exclure de votre archive. Vous n'avez pas besoin d'inclure les fichiers de log
dans l'archive, ou les fichiers  
master.info
  ou  
relay-log.info
 .Lorsque le verrou de lecture a été posé par  
FLUSH TABLES WITH READ LOCK
  et est en action,
lisez les valeurs courantes du fichie de log et de son offset sur le maître :| 
shell> tar -xvf /tmp/mysql-snapshot.tar
 | 
 La colonne  
File
  montre le nom du fichier de log, et la colonne 
 
Position
  affiche l'offset. Dans l'exemple ci-dessus, le nom du fichier
de log est  
mysql-bin.003
  et son offset est 73. Notez ces valeurs. Vous en 
aurez besoin pour configurer l'esclave.Une fois que vous avez pris une sauvegarde et enregistré le nom de fichier,
et son offset, vous pouvez réactiver l'activité sur votre maître :  
 
Si vous utilisez des tables  
InnoDB
 , l'outil idéal est  
InnoDB
  Hot Backup,
qui est disponible pour ceux qui achètent des licences commerciales MySQL, 
du support ou l'outil lui-même. Il fait un sauvegarde cohérente du maître,
enregistre le nom du fichier de log binaire et son offset,
pour que cette archive soit directement utilisée par l'esclave plus tard.
Pour plus d'informations sur cet outil, voyez 
 http://www.innodb.com/order.php .Sans  
Hot Backup
 , le mieux pour faire une sauvegarde rapide d'une base
 
InnoDB
  est d'arrêter le serveur, puis de copier les fichiers de données
 
InnoDB
 , leurs logs, et leur fichier de définition ( 
.frm
 ). Pour enregistrer
le fichier de log courant et son offset, vous devez utiliser les commandes suivantes 
lors de l'extinction du serveur :| 
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)
 | 
 Et ensuite, enregistrer le nom du fichier et son offset, lu dans le résultat
de la commande  
SHOW MASTER STATUS
  présentée précédemment. 
Une fois que vous
avez ces informations, éteignez le serveur  
sans déverrouiller
  les tables,
pour vous assurer qu'il va bien s'arrêter dans l'état que vous avez noté :| 
mysql> FLUSH TABLES WITH READ LOCK;mysql> SHOW MASTER STATUS;
 | 
 Une alternative, valable pour les deux types de tables MyISAM et  
InnoDB
 ,
est de prendre un export SQL du maître, au lieu d'une copie binaire.
Pour cela, vous pouvez utiliser l'utilitaire  
mysqldump --master-data
 
sur votre maître, puis exécuter les commandes SQL sur votre esclave. Toutefois,
c'est plus lent que de faire une copie binaire.| 
shell> mysqladmin -uroot shutdown
 | 
 
Si le maître fonctionnait sans l'option  
--log-bin
 , le nom du fichier
de log et l'offset seront vides, lorsqu'ils sont demandé à 
 
SHOW MASTER STATUS
  et  
mysqldump
  sera vide aussi. Dans ce cas,
utilisez la chaîne vide ( 
''
 )comme nom de fichier de log, et la valeur 
4 comme offset.
Dans le fichier  
my.cnf
  du maître, ajoutez les options  
log-bin
  et 
 
server-id=unique number
 , où  
master_id
  doit être un entier positif
entre 1 et 2^32 -{} 1, à la section  
[mysqld]
  et redémarrez le serveur.
Il est très important que l'identifiant des esclaves soient différents de celui
du maître. Pensez à  
server-id
  comme à une valeur 
comparable à une adresse IP : elle identifie de manière unique 
un serveur dans la communauté des réplicateurs. 
Si ces options ne sont pas présentes, ajoutez-les, et redémarrez le serveur.| 
[mysqld]log-bin
 server-id=1
 | 
Arrêtez le serveur qui va servir d'esclave, et ajoutez les lignes suivantes
dans son fichier  
my.cnf
  : 
La valeur de  
slave_id
 , comme la valeur de  
master_id
 , doit être
un entier, entre 1 et 2^32 -{} 1. De plus, il est très important que l'identifiant
de l'esclave soit différent de celui du maître. Par exemple :  
 
Si vous configurez plusieurs esclaves, chacun d'entre eux doit avoir
une valeur  
server-id
  distincte de celle du maître et des autres
esclaves. Pensez aux  
server-id
  comme étant des adresses IP : 
ces identifiants repèrent de manière unique un esclave dans la 
communauté de réplication.| 
[mysqld]server-id=slave_id
 | 
 
Si vous ne spécifiez pas de valeur pour  
server-id
 , il prendra la valeur
de 1 si vous n'avez pas défini de valeur pour  
master-host
 , sinon,
il prendra la valeur de 2. Notez que dans le cas où vous omettez 
 
server-id
 , un maître refusera laconnexion à tous les esclaves.
Par conséquent, omettre  
server-id
  est uniquement valable pour 
des opérations de sauvegarde avec log binaire.
Copiez la sauvegarde des données dans vos esclaves. Assurez vous que les
droits sur ces données sont corrects. L'utilisateur qui fait fonctionner
MySQL doit avoir les droits d'écriture et de lecture sur ces fichiers,
tout comme le maître l'avait.
 
Si vous avez fait une sauvegarde avec  
mysqldump
 , lancez d'abord les
esclaves (voir prochaine étape).
Redémarrez les esclaves. S'il était déjà configuré pour 
la réplication, lancez l'esclave avec l'option  
--skip-slave-start
 .
Vous pouvez uassi lancer l'esclave avec l'option  
--log-warnings
 . 
De cette manière, vous aurez plus de détails sur les problèmes que
l'esclave rencontrera (problèmes réseau, d'identification, etc.)Si vous avez fait une sauvegarde du maître avec l'utilitaire  
mysqldump
 , 
chargez l'export avec la commande suivante :  
| 
shell> mysql -u root -p < dump_file.sql
 | 
Exécutez la commande sur l'esclave, en remplaçant les valeurs entre
crochets  
<>
  par les valeurs que vous aviez lu sur le maître,
ou qui sont valables pour votre système :  
La table suivante vous donne les tailles maximales de ces variables :| 
mysql> CHANGE MASTER TO->     MASTER_HOST='<master host name>',
 ->     MASTER_USER='<replication user name>',
 ->     MASTER_PASSWORD='<replication password>',
 ->     MASTER_LOG_FILE='<recorded log file name>',
 ->     MASTER_LOG_POS=<recorded log offset>;
 | 
 
| MASTER_HOST | 60 |  
| MASTER_USER | 16 |  
| MASTER_PASSWORD | 32 |  
| MASTER_LOG_FILE | 255 | Lancez les threads esclaves. 
 
Après avoir suivi les instructions ci-dessus, les esclaves doivent se 
connecter au maître, et rattraper les modifications qui ont eu lieu depuis
la sauvegarde des données. 
Si vous avez oublié de spécifier un  
server-id
  pour un esclave, vous
allez obtenir l'erreur suivante dans le fichier d'erreur : Si vous avez oublié de le faire pour le maître, les esclaves ne pourront
pas se connecter avec le maître.Si un esclave n'est pas capable de faire la réplication pour une raison
quelconque, vous allez trouvez le message d'erreur dans le fichier de log
d'erreurs de l'esclave.| 
Warning: one should set server_id to a non-0 value if master_host is set.The server will not act as a slave.
 | 
 
Une fois qu'un esclave a activé la réplication, vous trouverez
deux fichiers dans son dossier de données : 
 
master.info
  et  
relay-log.info
 .
L'esclave utilise ces deux fichiers pour savoir où il en est des logs du maître.
 
Ne supprimer pas et n'éditez pas
  ces fichiers, à moins que vous
ne sachiez bien ce que vous faites. Même dans ce cas, il est préférable
d'utiliser la commande  
CHANGE MASTER TO
 .
NOTE
  : le contenu du fichier  
master.info
  est priorité par rapport
a certaines versions spécifiées en ligne de commande, ou dans le fichier 
 
my.cnf
 . Voyez  Options de réplication  pour plus de détails. 
Une fois que vous avez une sauvegarde, vous pouvez l'utiliser pour configurer
d'autres esclaves, en suivant la procédure concernant l'esclave, ci-dessus. Vous
n'aurez pas besoin d'une autre sauvegarde du maître.
 |